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

[L.M.H <lmh () info-pull com>]

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

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.

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 () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave