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

["Rodrigo Rubira Branco (BSDaemon)" <rodrigo () kernelhacking com>]

Hello Steve,


> I don't think theories really matter at this point. If I said I was busy I
was. But I've finished up my project and can now discuss this with you.

* No comments here.  I just believe in you ;)


> There are likely similar attacks to the NULL ptr issue. Its just a well
known/predictable invalid pointer dereference.

You need to understand how the segmentation works... answering another
question in your mail this feature have no documentation yet, but you can
read the code and ask for specific questions... I´m working with this
specific feature so maybe I can help you.

Another think you haven´t commented in your post is about the page
protection and kern stack randomization, that can protect your system to be
exploited, and if so, the kernel to be changed...  Also, I want to see more
ideas into kernel protection, like KERNSEAL, stmichael, and others.  The
patch to verify the signature of modules in redhat is another thing that can
be easily bypassed, using DMA or just changing a kdump/kexec kernel and
causing a crash... it is not?

The point is not to fix a vulnerability.  The point is turn it
unexploitable.  That´s what UDEREF does for NULL pointer derefs.

> Does grsecurity solve that?

Again our discussion (good discussion, tks for your position!) about
auto-learning ;)


Cya,


Rodrigo (BSDaemon).

--
http://www.kernelhacking.com/rodrigo

Kernel Hacking: If i really know, i can hack

GPG KeyID: 5E90CA19


--------- Mensagem Original --------
De: Steve Grubb <sgrubb () redhat com>
Para: Brad Spengler <spender () grsecurity net>
Cópia: dailydave () lists immunitysec com
Assunto: Re: [Dailydave] On exploiting null ptr derefs, disabling SELinux,
and silently fixed Linux vulns
Data: 14/05/07 18:18

> On Monday 14 May 2007 14:04, Brad Spengler wrote:
> &gt; &gt; I was very busy at the time and had no chance to reply until
now.
> &gt;
> &gt; I have a different theory on this, given the suspicious timing of
your
> &gt; post:
>
> I don't think theories really matter at this point. If I said I was busy I
> was. But I've finished up my project and can now discuss this with you.
>
> &gt; so to make it appear as though I wasn't right on every single point I
laid
> &gt; out, you limp in with your reply now two months later.
>
> No, I think you hit some really good points. I just don't have the
bandwidth
> to respond to every email all the time.
>
> &gt; &gt; Brad, thanks for pointing this out. I had heard rumors of an
exploit that
> &gt; &gt; could turn selinux off last year. I theorized what could be
attacked and
> &gt; &gt; saw that your exploit attacks exactly what I thought...a
variable used
> &gt; &gt; for yes/no decisions. So, I was happy that this was all you had
found.
> &gt;
> &gt; The problem is there's nothing you can do about my attack,
>
> There are likely similar attacks to the NULL ptr issue. Its just a well
> known/predictable invalid pointer dereference.
>
> &gt; &gt; It looks to me like you have the same exact attack point that
selinux
> &gt; &gt; does. Its just that one needs to loop through them to shut them
down.
> &gt; &gt; Wouldn't you agree on that point?
> &gt;
> &gt; It's absolutely true.
>
> Super.
>
> &gt; But we also don't make diagrams like those found in that recent RH
magazine
> &gt; article, nor do we talk about &quot;proven models&quot; and
&quot;information flow graphs&quot;
> &gt; since I've made it clear many times that these are pointless when
your
> &gt; kernel is compromised.
>
> 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.
>
> &gt; But as I'll talk  about a little more below, the bug I exploited to
disable
> &gt; SELinux was unexploitable with grsecurity due to the UDEREF feature
of PaX.
> I am not familiar with UDEREF. Do you have a white paper or some
discussion I
> could read to see what this is?
>
> &gt; &gt; Who says that all apps people run come from Red Hat?
> &gt;
> &gt; Good, so now we have the problem of 3rd party apps, where you claim
that
> &gt; someone can develop a policy from a black box system that wouldn't
allow
> &gt; 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. 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.
>
> 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.
>
> 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.
> The bottom line is that kernel vulnerabilities can be serious. It just
really
> depends on a case by case basis.
>
> &gt; You base this on an administrator &quot;seriously considering whether
the app
> &gt; needs the access or not,&quot; which is a complete side-step of the
issue.
> &gt; Administrators aren't as smart as you think they are.
>
> Does grsecurity solve that?
>
> &gt; If you happen to be in the situation of developing a policy for a
trojaned
> &gt; binary, chances are you've already lost the game.  Kernel exploits
have the
> &gt; notorious knack of having little to do with whether the binary can
write
> &gt; to /etc/shadow or not.
>
> Agreed.
>
> &gt; &gt; You don't need the source to write policy.
> &gt;
> &gt; You can write a policy, but it won't be good.  How do you magically
> &gt; predict future behavior of a blackbox application?  Again you
side-step
> &gt; 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.
>
>
> &gt; &gt; Any kernel vulnerability could have security consequences on any
kernel.
> &gt; &gt; You don't know until its reported, tested, and fixed.
> &gt;
> &gt; Here you're completely wrong (again).  In the case of my previous
> &gt; exploit, that particular kernel vulnerability or any in its class
cannot
> &gt; be exploited on a grsecurity-enabled system with the UDEREF feature
of
> &gt; PaX enabled.
>
> Right. And you just proved I'm not wrong. You have to test the problem. In
> your case maybe this one wasn't a problem. (But it was before you fixed
it.)
> &gt; It closes down this entire class of bugs.  So no, any kernel
vulnerability
> &gt; doesn't necessarily have security consequences on any kernel.
>
> Exactly my point.
>
> &gt; In this case, it had consequences on systems running
> &gt; SELinux.
>
> And systems without.
>
> &gt; Also, about the attack vector of disabling the RBAC system
> &gt; (which is what I think you'd really want to target, since the other
> &gt; sysctl toggleable values there you list are only useful against
non-root
> &gt; users -- not much point when you can own the kernel, right?)
>
> True. You could do a lot of things besides turning selinux off.
>
> -Steve
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave

________________________________________________
Message sent using UebiMiau 2.7.2

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