passing axel a url that doesn't exist causes it to crash... and if you give it a long url you get some interesting heap related errors... Possibly from a free(null) Ex: executioner@box:~/tmp/axel-1.0b$ axel A Initializing download: A Segmentation fault (core dumped) Ex2: executioner@box:~/tmp/axel-1.0b$ axel `perl -e 'print "A"x500'` Initializing the download: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA *** glibc detected *** ./axel: free(): invalid next size (normal): 0x0805a9a0 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7e18cb0] /lib/libc.so.6(__libc_free+0x84)[0xb7e1a2f4] /lib/libc.so.6(fclose+0x15b)[0xb7e0a20b] /lib/libnss_files.so.2[0xb7ef34c4] /lib/libnss_files.so.2(_nss_files_getservbyname_r+0x103)[0xb7ef3bc3] /lib/libc.so.6(getservbyname_r+0x82)[0xb7e87902] /lib/libc.so.6(getservbyname+0x8e)[0xb7e877ae] ./axel[0x804b8c9] ./axel[0x80496dd] ./axel[0x804efbd] /lib/libc.so.6(__libc_start_main+0xd8)[0xb7dcb878] ./axel[0x80491b1] ======= Memory map: ======== 08048000-08051000 r-xp 00000000 03:03 6406219 /home/rootfiend/tmp/axel-1.0b/axel 08051000-08052000 rw-p 00008000 03:03 6406219 /home/rootfiend/tmp/axel-1.0b/axel 08052000-08073000 rw-p 08052000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d96000-b7da0000 r-xp 00000000 03:03 11684770 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 b7da0000-b7da1000 rw-p 00009000 03:03 11684770 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 b7db5000-b7db6000 rw-p b7db5000 00:00 0 b7db6000-b7ecd000 r-xp 00000000 03:03 6471772 /lib/libc-2.4.so b7ecd000-b7ecf000 r--p 00116000 03:03 6471772 /lib/libc-2.4.so b7ecf000-b7ed1000 rw-p 00118000 03:03 6471772 /lib/libc-2.4.so b7ed1000-b7ed4000 rw-p b7ed1000 00:00 0 b7ed4000-b7ee3000 r-xp 00000000 03:03 6471788 /lib/libpthread-2.4.so b7ee3000-b7ee4000 r--p 0000e000 03:03 6471788 /lib/libpthread-2.4.so b7ee4000-b7ee5000 rw-p 0000f000 03:03 6471788 /lib/libpthread-2.4.so b7ee5000-b7ee8000 rw-p b7ee5000 00:00 0 b7ef1000-b7ef9000 r-xp 00000000 03:03 6471783 /lib/libnss_files-2.4.so b7ef9000-b7efb000 rw-p 00007000 03:03 6471783 /lib/libnss_files-2.4.so b7efb000-b7efc000 rw-p b7efb000 00:00 0 b7efc000-b7efd000 r-xp b7efc000 00:00 0 [vdso] b7efd000-b7f17000 r-xp 00000000 03:03 6471761 /lib/ld-2.4.so b7f17000-b7f18000 r--p 00019000 03:03 6471761 /lib/ld-2.4.so b7f18000-b7f19000 rw-p 0001a000 03:03 6471761 /lib/ld-2.4.so bfcd2000-bfce8000 rw-p bfcd2000 00:00 0 [stack] Aborted (core dumped) Reproducible: Always
CCing security for an audit, to know how this could be exploitable for a more severe issue. Actually a client-side crash is not a security issue.
upstream is said to be dead, waiting for a patch
There are also numerous problems with strncpy... for instance: line 40 in conn.c, strncpy( url, set_url, MAX_STRING ); should be: strncpy( url, set_url, MAX_STRING - 1); to make room for the NULL terminator there are lots more of these... not to mention MAX_STRING needs to be larger
Did anyone get in touch with anyone at all who was involved with the upstream project? I may be interested in personally becoming the upstream maintainer.
Executioner, could you also look at bug # 171836 ?
*** Bug 171836 has been marked as a duplicate of this bug. ***
Any news on this one?
*** Bug 173983 has been marked as a duplicate of this bug. ***
Created attachment 126998 [details, diff] Patch to fix unsafe strcpy calls I took a look at it, this seems clearly vulnerable to a classic buffer overflow .I wrote a corrective patch, I'll try to contact upstream to see if he can integrate it.
no response from upstream so far... drizzt, could you merge the patch please?
Patch applied
Thanks. Got a response from upstream in the meanwhile, but he doesn't seem very motivated to release a new version, so... arches, please test and mark stable net-misc/axel-1.0b-r2. Target keywords are: ~amd64 ppc ~ppc-macos ppc64 sparc x86 ~x86-fbsd"
x86 stable
ppc64 stable
sparc stable. BTW, the patch is full of "tab removed lines" (without a real content change) which makes it quite big (~39K) and probably will make harder the portability to new versions. Dunno if this was intentioned by some reason.
(In reply to comment #15) > sparc stable. > > BTW, the patch is full of "tab removed lines" (without a real content change) > which makes it quite big (~39K) and probably will make harder the portability > to new versions. Dunno if this was intentioned by some reason. > You're right, that's my fault as I use a hook for deleting trailing whitespaces when saving files in emacs. Sorry for the inconvenience, I'll probably remove this from my config. About new versions, I wouldn't worry too much as upstream is pretty much dead, and if he decides to do a new release, it will probably include this patch anyway.
ppc stable, ready for glsa-voting
voting NO.
Voting NO and closing.
