dear ILUG members Here are some serious flaws found in applications . These were discovered by as part of the graduate-level course at the University of Illinois at Chicago.
I have not checked the vailidity of the flaws.. hence i m not sure how serious they are... --------------------------------------------------------- NASM 0.98.38 error() overflows buff[] You are at risk if you receive an asm file from an email message (or a web page or any other source that could be controlled by an attacker) and feed that file through NASM. Whoever provides that asm file then has complete control over your account: he can read and modify your files, watch the programs you're running, etc. Of course, if you _run_ a program, you're authorizing the programmer to take control of your account; but the NASM documentation does not say that merely _assembling_ a program can have this effect. It's easy to imagine situations in which a program is run inside a jail but assembled outside the jail; this NASM bug means that the jail is ineffective. Proof of concept: On an x86 computer running FreeBSD 4.10, as root, type cd /usr/ports/devel/nasm make install to download and compile the NASM program, version 0.98.38 (current). Then, as any user, save the file 22.S attached to this message, and type nasm 22.S with the unauthorized result that a file named EXPLOITED is created in the current directory. (I tested this with a 525-byte environment, as reported by printenv | wc -c.) Here's the bug: In preproc.c, error() uses an unprotected vsprintf() to copy data into a 1024-byte buff[] array. ------------------------------------------------------ mpg123 0.59r find_next_file overflows linetmp You are at risk if you use mpg123 --list to take an MP3 playlist from a web page (or any other source that could be controlled by an attacker). Whoever provides that input then has complete control over your account: he can read and modify your files, watch the programs you're running, etc. Of course, when you accept a playlist from someone else, you are running the risk that the playlist will include some of your files, conceivably secret audio files. But the mpg123 documentation does not suggest that there is any larger risk. Proof of concept: On an x86 computer running FreeBSD 4.10, as root, type cd /usr/ports/audio/mpg123 make install to download and compile the mpg123 program, version 0.59r (current ports version; note that pre0.59s does not appear to have fixed the bug). Then, as any user, save the file 8.list attached to this message, and type mkdir 1234567890123456789 mv 8.list 1234567890123456789/8.list mpg123 -s --list 1234567890123456789/8.list >/dev/null with the unauthorized result that a file named EXPLOIT is created in the current directory. (I tested this with a 4621-byte environment, as reported by printenv | wc -c.) Here's the bug: In playlist.c, find_next_file() uses strcat() to copy any amount of data into a 1024-byte linetmp[] array. ------------------------------------------------------ MPlayer 1.0pre5 get_header overflows data buffer You are at risk if you use MPlayer to play an ASF video stream from the web (or from any other source that could be controlled by an attacker). Whoever provides that stream then has complete control over your account: he can read and modify your files, watch the programs you're running, etc. Proof of concept: On an x86 computer running FreeBSD 4.10 with ucspi-tcp installed, type wget http://ftp5.mplayerhq.hu/mplayer/releases/MPlayer-1.0pre5.tar.bz2 bunzip2 < MPlayer-1.0pre5.tar.bz2 | tar -xf - cd MPlayer-1.0pre5 ./configure gmake to download and compile the MPlayer program, version 1.0pre5 (current). Then save the file 17-s.c attached to this message, and type gcc -o 17-s 17-s.c tcpserver 0 1755 ./17-s & ./mplayer mmst://127.0.0.1/new_video.asf with the unauthorized result that a file named x is removed from the current directory. (I tested this with a 538-byte environment, as reported by printenv | wc -c.) Here's the bug: In asf_mmst_streaming.c, get_header() uses get_data() to copy an input-specified amount of data into a 102400-byte data[] array. ------------------------------------------------------ A CUPS installation is at risk whenever it prints an HPGL file obtained from email (or a web page or any other source that could be controlled by an attacker). You are at risk if you print data through a CUPS installation at risk. The source of the HPGL file has complete control over the CUPS ``lp'' account; in particular, he can read and modify the files you are printing. Proof of concept: On an x86 computer running FreeBSD 4.10, as root, type cd /usr/ports/print/cups make install to download and compile the CUPS package, version 1.1.22 (current). Then, as any user, save the file 21.hpgl.gz attached to this message, and type gunzip 21.hpgl /usr/local/libexec/cups/filter/hpgltops \ 15 $USER test-title 1 none 21.hpgl > 21.ps with the unauthorized result that a file named x is removed from the current directory. (I tested this with a 541-byte environment, as reported by printenv | wc -c.) Here's the bug: In hpgl-input.c, ParseCommand() reads any number of bytes into a 262144-byte buf[] array. ---------------------------------------------------------- see all the other flaws at:: http://tigger.uic.edu/~jlongs2/holes/ so be careful bye sameer ===== Sameer Mohamed Thahir ([EMAIL PROTECTED]) __________________________________ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com
