[Dailydave] Kernel 'developer' makes fuzzy FUD (RH Episodes: Volume 1)

[PERFECT.MATERIAL]

Dear HD Moore Wannabe, Yet Still Much Dumber Than HD Moore,

>
> There's something that strikes me, why a bug 'with no security
> implications' is marked as private to Red Hat employees? I was about
> to look for the 'EYES ONLY' mark but didn't find it, yet.
>

Is this your in depth technical analysis into the exploitability of
the bug in question? Pointing out that "the vendor is taking it
seriously as opposed to as a joke" does not validate this bug at all.
Just wanted to make sure you didn't take the time to look into this
bug yourself. I am hopeful that by raising this question, you will be
forced to realize that you should stop blabbing and cross posting
harassing e-mails to bloggers.

I don't have a blog so I would like to just ask you here. Why is it
that you consider this bug to be serious? Why do you consider that
blogger guy downplaying the severity of the bugs to be FUD? Let me
quote your quote, including your fancy '-- quote' marker technology.

-- quote
> -- quote
> For example, nine days into the "month of kernel bugs", we've yet to
> see a Linux kernel bug that allows the user to do anything other than
> crash/oops the kernel. Code execution hasn't been proven at all. (And
> conveniently, lets ignore that you need either a) root privileges to
> mount an image over loopback or b) physical access to insert a corrupt
> CD/USB key).
> -- end quote
-- end quote

Ok, so let us do what the silly blogger said and ignore the
exploitability issue since you clearly aren't qualified to comment on
it (but do anyway). How do you explain the root privilege or physical
access requirement? I have several 0day hacker bugs that allow you to
hack OR crack a machine given physical or root access. I even know of
some publicly available methods...

I think you should give it up. There is only room for one annoying
fuzzer blog on this megaweb and Thor Doomen has made sure that that
spot is filled. I hereby call for you to halt the month of worthless
bugs project and delete the content of the blog immediately. Thanks.

PERFECT.MATERIAL
"I love all of you -- and especially your wives," - James Strom Thurmond

On 11/11/06, L.  M. H <lmh at info-pull.com> wrote:
> Hi,
>
> I've been noticed about about a post by 'Dave Jones' on his 'Kernel
> slacker' blog:
> http://kernelslacker.livejournal.com/62905.html
>
> -- quote
> For example, nine days into the "month of kernel bugs", we've yet to
> see a Linux kernel bug that allows the user to do anything other than
> crash/oops the kernel. Code execution hasn't been proven at all. (And
> conveniently, lets ignore that you need either a) root privileges to
> mount an image over loopback or b) physical access to insert a corrupt
> CD/USB key).
> -- end quote
>
> OK, enough FUD already.
>
> Fortunately, this time I won't have to explain the security
> implications of the zlib bug. I want to thank Red Hat fellows for
> explaining it already, in a private bugzilla entry of course.
>
> Copy of printer-friendly version at:
> http://projects.info-pull.com/mokb/redhash/show_bug-211668.ps

> Well, back to the bug itself. Dave, I'll quote this one:
>
> -- quote
> Whilst LMH's fuzzer is pretty neat, the Gartner write-up gives the
> impression that kernel developers spend all day complacently idling in
> the belief that everything is perfect.
> -- end quote
>
> Well, you wasted your time writing a completely non-sense post to your
> blog, instead of going back to your company's bugzilla and reading the
> whole thread about the bug. Please make sure you've read Phillip
> Lougher's comments that nicely explain the issue:
>
> -- quote
> The line "Error -3 while decompressing!" is printed after zlib_inflate has
> returned.  What then happens is cramfs_uncompress_block returns 0 bytes
> which
> means cramfs_readpage returns a completely zero-filled block.  This means
> the
> "Unable to handle kernel paging request at 000000002252d15d RIP:" can't be
> generated by cramfs_readpage returning failure, because it never does.  This
> means it is probably caused by stack corruption or other memory corruption.
>
> The error line "ffffffff8852d146(-1711276009)->ffff810033dad000(4096)" is
> generated by cramfs_uncompress_block which I think indicates the error.  The
> size of the source block is given as -1711276009, which both zlib_inflate()
> and
> cramfs_read() handle as an unsigned int, or a large number.  Cramfs_read()
> doesn't fall over reading this because it never reads more than BUFFER_SIZE
> bytes (16K, 4*PAGE_CACHE_SIZE), but it is likely zlib_inflate() is
> corrupting
> memory given such a large block to evaluate/checksum.
>
> Ultimately, the bug is caused by the corrupted block length field read by
> cramfs_readpage().  The fix is to add a sanity check in cramfs_readpage()
> when
> the block length is read.
> -- end quote
>
> Luckily enough I'm feeling good today, if not, I would rather tell you
> to STFU and do your homework. You're probably a nice guy, so I just
> recommend to not continue walking through this suicidal route.
>
> That's the not-so-good advertisement you should care about, rather
> than trying to obscure what is an obvious issue. If you're having some
> sort of pressure from somewhere else, then I'm sorry for you.
>
> I'm not an expert, I probably have much less kernel development
> experience than you do, but I know my stuff. I'm not a 'self
> proclaimed security researcher' (please point me at a single line
> where I've actually said that, and I'll rip off my testicles and sell
> them on eBay) as I've read in some places (recall a "Mac zealot" blog
> so far).
>
> BTW, next time you want to discuss something like this, send me an
> e-mail. I won't bite you, I promise. I find it extremely off to find
> how 'blogs' are being used out there (lemme use the term 'blog
> whoring').
>
> Cheers.
> PS: I'm CC'ing HD, he may be able to comment on when 'non exploitable
> bugs' become 'exploitable', without some obscure 'black hat Russian
> voodoo magic' involved.
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>