En ocasiones, estamos desarrollando una aplicación, y ésta necesita que le pasemos como parámetro, por ejemplo, una contraseña. El gran peligro que esto tiene es que cualquier usuario, pidiendo un listado de procesos con ps podrá ver la contraseña.

Imaginemos que tenemos una aplicación (que hemos hecho nosotros) que conecta con un servidor, y dado que hemos hecho un script para automatizar el proceso, el nombre de usuario y contraseña los pasaremos como parámetro al ejecutable. Dicho proceso se llama “aplicacionsegura”, dicho programa lo hemos lanzado en un servidor y otros usuarios tendrán acceso a dicha máquina. Ahora uno de ellos ejecuta lo siguiente:

$ ps ax
….
10560 pts/3    S+     0:00 ./aplicacionsegura –user=usuario –passwd=micontraseña
…

¡Nuestro gozo en un pozo! Otro usuario ya tiene nuestra contraseña, y ha sido muy sencillo. Y además lo podremos ver (de hecho ps es lo que hace) viendo el archivo /proc/PID/cmdline. Aunque debemos ver qué opciones tenemos:

Modificar el parámetro passwd

Para ilustrar el ejemplo, vamos a fijar la posición de –passwd=xxxxx al segundo parámetro (la captura de parámetros no es objeto de este post). Lo primero que vamos a probar es introducir un terminador en las cadenas de los parámetros, Si la cadena empieza por ‘\0′ estará vacía:

Aunque tardaremos poco en darnos cuenta que da igual, por una parte, no podríamos borrar todos los rastros de información, ya que si escribimos en la posición 0 de la cadena “–passwd=micontraseña” un terminador, el resto de la cadena se quedará en memoria y podrá ser leída. De todas formas, la cadena parece que sólo tiene un espacio para ps, es más, el \0 le ha dado igual.

Probemos ahora escribiendo “HOLA” en la cadena de la contraseña (ahora sí pongo el código completo, test.c):

Ahora ejecutaremos lo siguiente:

$ gcc -o test test.c
$ ./test & # El programa test esperará una tecla para terminar, pero lo ejecutaremos de fondo, para que no se cierre.
$ ps ax
….
10809 pts/3 S+ 0:00 ./test –user=usuario –passwd=HOLA traseña
….
$ killall test # Para matar el proceso

Un efecto curioso, las cadenas de los parámetros no son NULL-terminated, de cara a /proc/PID/cmdline por lo que cuando ponemos un terminador, lo toma como un espacio. Y se ve parte del parámetro. Lo que sí podemos hacer es sustituir por asteriscos, tantos asteriscos como letras tenga el parámetro.

Ahora al ejecutar ps:

$ ps ax
…
10906 pts/3 S+ 0:00 ./test –user=******* –passwd=*************
…

Aunque esta forma revela en cierto modo la longitud de las contraseñas y el nombre de usuario, puede que no nos interese, que queramos eliminar el parámetro entero y que no se vea:

La manera rápida pero peligrosa y de andar por casa

El objetivo es escribir algo más largo que el último parámetro. Es decir, si el parámetro de contraseña tiene 22 letras, tenemos que escribir algo más grande, unas 23 letras, o cargarnos el terminador del segundo argumento (no son NULL-terminated, el kernel sabe dónde empieza y dónde termina la cadena, pero hay un NULL para comprobar que todo va bien).

En este caso podemos hacer:

y veremos cómo ps no nos dice nada, en principio no es demasiado elegante, nos estamos cargando un terminador, que nosotros podríamos necesitar, para lectura, y estamos escribiendo en una zona de memoria que no es nuestra, ya que el argumento tiene reservado un tamaño de memoria, y estamos escribiendo más de lo que debemos (podemos producir una violación de segmento).

Decirle al kernel que no queremos los parámetros

Parecida a la forma anterior, podemos hacer:

lo que no es intuitivo para nada, porque nos estamos cargando el terminador, que controla el paso de parámetros. De esta forma, no tendremos ningún parámetro. Tambén podemos hacer una forma general

De esta forma desaparecerán todos los argumentos de /proc/PID/cmdline ; sólo tendremos la ruta y el nombre del ejecutable, y nuestros datos, al menos por esta parte, estarán seguros.
Foto: marc falardeau (Flickr)

GCC compila y linka automáticamente, nos devuelve un ejecutable directamente:

$ gcc -o ejecutable fuente.c

pero en realidad, aparte de pre-procesar y compilar, enlaza algunas bibliotecas del sistema para que nuestro ejecutable funcione bien. Sólo por jugar un poco, veamos, más o menos (depende del sistema) cómo obtener el ejecutable a mano, es decir, compilamos por un lado, y linkamos por otro.

Primero, creamos un programa sencillo, un hello.c que contenga lo siguiente:

Ahora obtenemos el fichero objeto, nuestro código compilado de la siguiente manera:

$ gcc -c hello.c

Veremos que se ha generado el fichero hello.o ; éste fichero aún no lo podremos ejecutar, ya que no tenemos las librerías del sistema necesarias para ello.

Ahora obtendremos el fichero ejecutable con el linkador:

ld -o hello -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3 hello.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtend.o /usr/lib/crtn.o -lc

Debemos cambiar /usr/lib/gcc/i686-pc-linux-gnu/4.2.3 por la ruta correspondiente en nuestro equipo; los archivos necesarios se encontrarán en en el directorio de GCC, tras seleccionar la arquitectura y SO correspondiente (en mi caso i686-pc-linux-gnu), y dentro de ese directorio encontraremos otro correspondiente a la versión de GCC (en mi caso la 4.2.3).

Más o menos lo que vemos en el proceso de linkado es lo siguiente:

• -o hello : es el nombre del ejecutable
• -m elf_i386 : es el tipo de ejecutable y la arquitectura. También puede ser elf_x86_64 si tenemos las bibliotecas necesarias.
• -dynamic-linker /lib/ld-linux.so.2: es el cargador dinámico
• /usr/lib/crt1.o /usr/lib/crti.o: son dos objetos encargados de la inicialización de memoria del programa
• /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtbegin.o : indica cómo tiene que empezar el programa.
• /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtend.o : indica cómo tiene que terminar el programa
• hello.o : es el objeto de nuestro programa.
• -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3 : hacemos que el linkador busque bibliotecas en el directorio indicado.
• /usr/lib/crtn.o : realiza tareas de limpieza de memoria.
• -lc: incluye la librería de C estándar.

Los archivos que empiezan por crt* normalmente se encargan de poner los datos que nos entran en su sitio; parece que el hecho de coger los parámetros que nos pasan por la línea de comandos y colocarlos en memoria para que nuestro programa los lea es tarea fácil, y que luego nuestro programa devuelva una respuesta; y además, los programas no se ejecutan siempre en la misma posición de memoria, depende de la memoria que haya libre, eso lo suele controlar el S.O. pero nuestros ejecutables tienen que estar preparados… en definitiva, hay muchos agentes involucrados.

Una vez hecho esto, tenemos nuestro hola mundo preparado para ser ejecutado.

Debo agradecer a Carlos, que me dio la idea de escribir este artículo.

Es muy de 2002/2003, aunque todavía a muchos les gusta tener un pequeño terminal transparente en el fondo para ejecutar comandos o mostrar logs u otra información importante.

Aquí comentaré algunas soluciones que he encontrado y cómo obtenerlas.

xrootconsole

Es muy ligero y rápido. Y vale para mostrar logs en xroot; el fondo es supuestamente transparente, aunque si cambiamos el fondo veremos que no, ya que en la ventana de xrootconsole se mantendrá el fondo anterior. Está bien para hacer el apaño, pero no lo recomiendo. La forma de ejecutar xrootconsole es:

$ xrootconsole [fichero]

donde fichero es el que vamos a vigilar, la visualización se actualiza automáticamente con cada cambio que se observa en el archivo. Es ideal para ver /var/log/messages.

aterm

Muestra un terminal transparente, con muchas opciones, y que podemos ejecutar de la siguiente manera para mostrar las últimas líneas de dmesg en el escritorio:

$ aterm -fg black -geometry 100×10+0+0 -e watch –no-title -n10 -d ‘dmesg | tail’

donde:

Por supuesto podemos sustituir el comando que esta en negrita por lo que queramos mostrar.
Aún así, de esta forma aterm nos muestra decoración de ventana, barra de scroll y no es transparente. Esto lo podemos solucionar ejecutando aterm de la siguiente manera:

$ aterm -tr -bl -sb -fg black -geometry 100×10+0+0 -e watch –no-title -n10 -d ‘dmesg | tail’

O, editando el archivo $HOME/.Xdefaults y añadiendo estas líneas

aterm*transparent:true
aterm*borderLess:true
aterm*scrollBar:false

El problema de aterm es que no admite sombra en las letras, por lo que la lectura sobre algunos fondos es algo complicada.

Eterm

Este emulador de terminal es el más completo y tiene más opciones, y por lo menos es el que soporta poner sombra en las letras, lo que proporciona una mejor visibilidad, y es el que aparece en la captura de pantalla que hay arriba. Para ello, lo podemos ejecutar de la siguiente forma:

Eterm –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’

Aunque veremos un problema, la decoración de la ventana, para ello hay varias soluciones, dependiendo del sistema en el que trabajemos, para muchos, la solución será incluir el parámetro -x:

$ Eterm -x –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’

(en negrita aparece el comando, en cursiva un comando opcional), aunque a veces el entorno de ventanas, entre ellos Fluxbox, el que uso actualmente, no se lleva muy bien con ese modo sin decoración de ventanas, y aunque se muestra bien, la ventana aparece sobre todas las demás (on top).
Para solucionar eso, nos vamos a complicar un poco la vida. Para ello, editamos el archivo $HOME/.fluxbox/apps y añadimos las siguientes líneas:

[app] (name=dmessenger)
[Deco] {NONE}
[Sticky] {yes}
[Layer] {10}
[end]

Y a la hora de ejecutar Eterm lo hacemos de la siguiente manera:

Eterm –buttonbar 0 –scrollbar off -f white -n dmessenger -g 211×10+0+0 -O -0 -e watch –no-title -n10 -d ‘dmesg | tail’ & sleep 2 && wmctrl -r dmessenger -b add,skip_taskbar

donde ejecutamos Eterm en segundo plano (al terminar el comando con &) y ejecutamos un sleep 2 (para esperar 2 segundos antes de ejecutar el siguiente comando), a continuación ejecutamos wmctrl donde,

dmesg

En el ejemplo estamos ejecutando dmesg de la siguiente forma (con la ayuda de watch):

watch –no-title -n10 -d ‘dmesg | tail’

donde,

Esta serie de posts está dedicada a tod@s mis alumn@s de clases particulares de programación. Iré añadiendo información de diferentes niveles, dificultades, colores y sabores. Espero que les parezca interesante.

Fue en el primer año de carrera, cuando en la asignatura Fundamentos de Programación y luego en Laboratorio de Programación cuando empezábamos a hacer los primeros programas en C; yo hasta entonces no me había atrevido a programar nada en C, prefería Pascal, al menos llegué con una buena base de programación.

El IDE que utilizábamos (Dev-C++) directamente escribía las primeras líneas de programa:

#include

using namespace std;

int main(int argc, char *argv[])
{

}

Comprendo que en 4 meses hay que enseñar a mucha gente a defenderse con la programación, y no es objeto explicarlo todo detalladamente, aunque cuando alguien preguntaba siempre decían: “Eso hay que ponerlo siempre” es más, nada más empezar el curso, poca gente se va a enterar de qué va el asunto

Bien, empezamos por el include (vale, esto sí que lo contaban mis profesores, porque a veces teníamos que incluir alguna cosa más), incluir funciones y clases hechas por otras personas, y no nos tiene que importar cómo están hechas por dentro.

Un concepto más peliagudo y extenso es el de la línea siguiente: using namespace std (nos metemos a pelear con los espacios de nombres; no quiero ser demasiado extenso, pero imaginemos que hay dos casas en una calle, y cada casa aloja a tres personas: Jose, Virginia y Antonio en la casa A; y Alfonso, Manuela y Jose en la casa B. ¿Cómo distinguimos a Jose de la casa A de Jose de la casa B? Suena a pregunta tonta: Pues casaA::Jose y casaB::Jose, son dos personas diferentes.
Lo mismo podemos hacer en C++, podemos tener funciones que se llaman igual en espacios de nombres (o casas) diferentes, y para referirnos a ellos tenemos que decir primero en qué casa están, para que luego el compilador sepa ubicar a cada uno.
Pero como las pulsaciones de teclado de los desarrolladores son oro (sabemos que tenemos que escribir mucho, si podemos ahorrar algo mejor), y sabemos que muchas de las clases y funciones que vamos a utilizar pertenecen a la librería estándar (o std), es decir, estarán en la mansión std decimos:
using namespace std;
o lo que es lo mismo: si no te digo nada, y llamo a alguien que no encuentras, búscalo en std.

Llegamos al main(), podemos definirlo de muchas formas: muchos utilizan void main() (y gcc se queja), otros int main() (que es perfectamente válido), pero algunas veces se introduce toda esa parafernalia rara de int argc, char *argv[], que es impronunciable, y hace daño a la vista, e incluso si lo intentamos escribir las primeras veces, no nos saldrá igual.
Estos parámetros son para los argumentos del programa, es decir, para los parámetros que introduzcamos en la línea de comandos. Para muchos usuarios que vienen de Windows, les resulta raro entender por qué un programa requiere parámetros, pues bien: si abrimos Mi PC, nos vamos a una carpeta y abrimos un documento, cómo sabe Microsoft Office que hemos abierto este documento? Se lo hemos pasado como parámetro sin querer
Ahora bien, y esto requiere un poco de imaginación si estamos empezando:
argc es un número que indica el número de parámetros que tiene el ejecutable:

Veamos qué pasa al ejecutarlo:

$ ./params
Me has pasado: 1 parámetros
$ ./params param1 param2 “parametro 3″
Me has pasado: 4 parámetros
$ ./params param1 param2 “parametro 3″ “parametro 4″
Me has pasado: 5 parámetros

Nos sobra uno no? Veamos cuáles son esos parámetros:

Salida:

$ ./params param1 param2 “parametro 3″ “parametro 4″
Me has pasado: 5 parámetros
Parámetro 0: ./params
Parámetro 1: param1
Parámetro 2: param2
Parámetro 3: parametro 3
Parámetro 4: parametro 4

Vemos que el parámetro 0 es el propio nombre del ejecutable y comprobamos que si cambiamos el nombre del ejecutable, podemos saberlo con ese parámetro 0. Los demás podemos averiguarlos recorriendo la variable argv. argv es un Array de punteros de tipo char o lo que es lo mismo un array de cadenas de caracteres puesto que cada parámetro es una cadena de caracteres.

Ahora la pregunta del millón, si utilizamos un array, para qué necesitamos argc ¿? Podríamos averiguar el número de elementos del mismo. La respuesta es que no, de ese Array desconocemos el número de elementos que tiene (depende de lo que nos pase el usuario), y si tenemos un método para calcular el número de parámetros que tenemos, que seguro que podremos encontrarlo, será mucho más rápido disponer de ese valor (y escribimos menos)

A veces tenemos la necesidad de reemplazar un texto dentro de una cadena larga. Por ejemplo, el uso principal que le doy a esta función es el procesamiento de plantillas para páginas web, en donde tengo la página en HTML puro por un lado, y en su interior hay ciertas palabras clave, por ejemplo —seccionA—, —fotoUsuario—, —menuSesion—, etc; y en la web definitiva, aparecerá otra cosa en lugar de ese texto, aparecerá el objeto al que hace referencia.
Aunque cada cadena de texto seccionA, fotoUsuario, requiere un procesamiento distinto y es posible que no tengamos por qué procesar siempre todas las equivalencias de todos los textos. Queremos en definitiva reemplazar —seccionA— por el resultado de una función que ejecutaremos cuando encontremos ese texto. Sería como:

Aunque, como dijimos, en el ejemplo anterior, se tienen que ejecutar dibuja_seccionA(), get_fotoUsuario() y dibuja_menuSesion().

Pero podemos aprovecharnos de las expresiones regulares, para extraer texto que esté entre “—” y “—” y pasar lo que hay entre medias a otra función que decidirá qué hacer; eso hace preg_replace_callback().

Hasta aquí bien, el primer parámetro es una expresión regular (es un tema muuuy extenso), el segundo es la función a la que llamamos cuando encontramos el texto, y el tercero es de dónde lo sacamos. Bueno, ahora surge un problema, imaginad que necesito pasarle parámetros a esa función callback. Lo podemos hacer así:

Nota: las variables $datos_usuario, $datos_sesion y $web no están definidas, como esto es parte de un programa, hay que imaginar un poco cuál será la información que contendrán.