[sf-lug] Hacked RHEL4/PHP4 server

[Rick Moen]

Quoting Kristian Erik Hermansen (kristian.hermansen at gmail.com):

> Rick, you take my hypothetical situation too far.  My point was to
> prove that just parsing a file system *can* result in arbitrary code
> execution.  You do not need to have loadable boot code...

I await your exploit code aimed at canonical fsck.ext2 with interest
(albeit no held breath) -- and meanwhile, I assume my hypothetical Sidux
RAMdisk will continue to quake in terror.

> Bugs like this do exist, and here is a recent one for Mac OS X, which
> you claim should not be vulnerable to fsck running arbitrary code of
> the attacker's choosing merely because it does not run code in the
> boot sector when mounted...

I made _no_ such claim.  You may recall I carefully expressed doubt
specifically about OS X, specifically because of uncertainty about and
unfamiliarity with its eccentricities.

In any event, your example shows nothing of the kind.  Again, you need
to razzle-dazzle someone a bit more credulous.  Quoting (emphasis mine):

    MAY lead to an unexpected application termination or arbitrary 
    code execution

This means that some Apple engineer uncovered a coding screwup in their
ex-NeXTStep fsck utility for the heavily deprecated "UFS" (really FFS)
filesystem[1] where, probably, somebody failed to do bounds-checking or
something like that.  Which means that feeding it malformed data might
cause a code blowup, or under some extremely speculative conditions
could maybe, possibly, if the wind's in the right quarter and it's the
right phase of the moon, allow the local attacker to land something of
his/her choosing in an inappropriate part of the memory map, whence,
maybe, possibly, it might be possible to get some usefully privileged
process to jump to it as executable code.

This is an utterly typical "Oops, we screwed up C Variables 101" bugfix,
where nobody's ever come within a country mile of creating an exploit,
and no special reason exists to believe it's even feasible in a million
years of trying, but the bug's worth fixing anyway.

> The Monkey virus was pretty cool, but I'm not going down that path.
> I'm not talking about taking a file system hostage.  What I am talking
> about is something different.

I knew entirely well what you were talking about, Kristian.  And you
were ignoring _my_ point:  I already knew that you cannot trust any part
of a root-compromised filesystem back when God was a teenager, and
therefore you do not run any code on it.  You can natter on at length
about additional theoretical attack scenarios where even the _data_ are
scary and horrible with nasty, sharp teeth -- but, sorry, I'll take 
that threat seriously -- and worry about the awesome and horrifying
threat to my diagnostic RAMdisks -- when you produce relevant exploit
code.

Didn't I already say that?  I did, I see.  So, obliging me to repeat
myself is wasting your time, as well as mine.


[1] One of the reasons why they've been so slow in finding critical bugs
in their "UFS" implementation is that they strongly discourage its use
in favour of the inferior HFS+ filesystem -- and, in the real world,
almost nobody uses "UFS" on OS X, in consequence.  And why does Apple 
heavily promote an inferior filesystem over a technologically better
one?  Because HFS+, though a relative dungheap in every way, has the
advantage for traditional MacOS users of treating filenames as
case-insensitive, and Apple felt the poor little tykes' brains would
break if they had to deal with the concept of "Filename" being distinct
from "filename".