Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns

[<assault () hush com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Mon, 14 May 2007 22:45:32 +0300 Steve Grubb <sgrubb () redhat com>
wrote:

> I would absolutely agree with this statement. What these graphs
> are supposed
> to be illustrating is that you can't even get to the point of
> running your
> exploit in many cases.

thoze grafs, mind u, are hilarious. (like the rest of your mail :)

the way i understand it what your shit says is that if someone
pwnz0rz your webserver they dont necessarily have control over
other stuff like named and ntpd. while this may sell to the clowns
that run the show @ redhat, i hope u do understand that an
attacker's goal isn't always the same. if, hypothetically, selinux
really did "compartmentalize" the impact of a vulnerability to a
single service ("domain"), trust me, i can come up with enough
creative ways to fuq u up more than u think. heard of "defense in
depth"? well u can call this "attack in depth".

> I am not familiar with UDEREF. Do you have a white paper or some
> discussion I
> could read to see what this is?

zomg. separate. address. space. what is it you do for redhat again?

> > > Who says that all apps people run come from Red Hat?
> >
> > Good, so now we have the problem of 3rd party apps, where you
> claim that
> > someone can develop a policy from a black box system that
> wouldn't allow
> > any kind of trojan activity.
>
> This is somewhat true. You would have to determine if the program
> was
> installed trojaned or became trojaned after installation.

lol

> If it
> was installed
> trojaned, it might contain a kernel exploit and then all bets are
> off. If it
> was not installed with a trojan in it, there should have been a
> time when you
> were able to write good policy for it.

you must be living in a different world than mine

> But there are actually many things that have to happen to get a
> program
> trojaned. There is execshield which helps somewhat. By itself it
> doesn't
> solve all problems. Then there are security mechanisms in gcc to
> help
> discover buffer overflows and the FORTIFY_SOURCE options for glibc
> will also
> help checkout many of the dangerous functions. Ulrich Drepper
> lists much of
> this work in a paper you cited.

u lost me on the gcc thing

> If someone manages to bypass all that with SE Linux policy, they
> could very
> well take advantage of a kernel exploit as long as they make calls
> allowed by
> that domain or calls in which the exploit occurs before the
> permission check.

k this must stop now... do u have real numbers as to how many
admins write their own policies, how well they work, and can show
some policies written by admins outside redhat?

i'm going to throw a stat here that says this. i think % of admins
who are skilled enough to write a proper policy and actually take
the time to do that for the systems they admin is less than 5%. i
also think that a security policy for a complicated application is
going to be "loose" enough that will allow some amount of freedom
to play with what is possible within the domain to make a
substantial amount of damage. and i'm going to repeat a point i
made above clearer. i think that when code execution in the context
of a service (program that others interact with) is possible, it's
game over.

prove me wrong.

> The bottom line is that kernel vulnerabilities can be serious. It
> just really
> depends on a case by case basis.

i'm speechless. :)

> > You base this on an administrator "seriously considering whether
> the app
> > needs the access or not," which is a complete side-step of the
> issue.
> > Administrators aren't as smart as you think they are.
>
> Does grsecurity solve that?

is redhat building its products based on what other people, namely
grsecurity, are doing? will redhat fix flaws in its products only
when everyone else do?

> > If you happen to be in the situation of developing a policy for
> a trojaned
> > binary, chances are you've already lost the game.  Kernel
> exploits have the
> > notorious knack of having little to do with whether the binary
> can write
> > to /etc/shadow or not.
>
> Agreed.

oh bringing up /etc/shadow was so 1997

> > > You don't need the source to write policy.
> >
> > You can write a policy, but it won't be good.  How do you
> magically
> > predict future behavior of a blackbox application?  Again you
> side-step
> > the issue.
>
> You can write policy, run the app, see what AVCs come up, see if
> they sound
> reasonable, allow them, rinse and repeat as needed. There comes a
> point where
> you've exercised most behavior.

lol

that's a top 10. let me get this straight: u claim that all^Wmost
execution paths in an application will be exhausted by just running
it? do u have any idea how many problems that could have solved?

i wish i could draw u a diagram. here are two statements: people
are the weakest link in the security chain. selinux depends on
people for its security. do u see something wrong?

> > In this case, it had consequences on systems running
> > SELinux.
>
> And systems without.

i think his point was "stop selling snake oil u retard" (i added
the u retard)

assault
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkZI1foACgkQwRKs9FnnsLQ0qQP/fpZPDpJBkXnnNvSq56EEG+TReDwj
DvJyby0Qkil45Rro7L5wLRRwTWMM6hT6EZ0GHuwqTuv9ezL3lOBuIIMaDRLVeyHHhJBc
1B485+1h1Aya3B3FH4ekk8vFGrUiyxy/8cwHI89VtR2owD0rzZW95JHRw8S81mN8Mif+
n+tUZD0=
=5zQ/
-----END PGP SIGNATURE-----


_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave