Message-ID: <CAP145ph7B7Sa4bZmScQpkGWcscwO57Df-Abg7YL3h=GRjqFRMA@mail.gmail.com>
Date: Thu, 27 Mar 2014 18:39:52 +0100
From: Robert Święcki <robert@...ecki.net>
To: fulldisclosure@...lists.org
Subject: Re: [FD] Adventure with Stack Smashing Protector (SSP)

2014-03-27 4:08 GMT+01:00 Adam Zabrocki <pi3@....com.pl>:

> Hi,
>
> One weekend I decided to analyze Stack Smashing Protector (SSP) code. I
> believe some of the observations I've made might also be interesting to
> others. Because of that I've created a not so small write-up...
> ... which can be summarized (without necessary details) as:
>
>
> Not security related…
>
> 1. We can change program’s name (from SSP perspective) via overwriting
> memory region where
>    pointer to "argv[0]" points to.
> 2. We can crash Stack Smashing Protector code in many ways:
>      a. Via corrupting memory region pointed by "__environ" variable.
>      b. Via setting "LIBC_FATAL_STDERR_" to the edge of valid addresses.
>      c. Via forcing "alloca()" to fail – e.g. stack exhaustion.
>      d. There is one more bug which I’m analyzing more comprehensively at
> point 4. It may
>         indirectly force SSP to crash. It exists in the DWARF stack
> (state) machine which is responsible
>         for gathering information about the stack trace ("__backtrace()")
> and prints it.
> 3. We can slightly control SSP’s execution flow. (Un)Fortunately it
> doesn’t have any influence for the
>    main execution (what about security?). Following scenarios are possible:
>      a. Force SSP to open "/dev/tty"
>      b. Force SSP not to open "/dev/tty" and assign to the "fd" descriptor
> "STDERR_FILENO" value:
>
> #define STDERR_FILENO 2 /* Standard error output. */
>
>     c. Crash SSP via 2b. scenario
>
> 4. We can indirectly crash SSP via the unwinding algorithm (read-AV or we
> can be killed by
>    "gcc_unreachable" or "gcc_assert" function) – DWARF stack (state)
> machine:
>      a. Simulate FDE object was not found
>      b. Simulate FDE object was found.
>
>
> Somehow security related…
>
> 1. We can force SSP to allocate a lot of memory and cause Denial of
> Service via Resource Exhaustion
>    attack.
> 2. Theoretical Information leak:
>      a. Stack cookie information leak.
>      b. Any kind of information leak
>      c. File corruption.
>


Hi Adam,

Quite an interesting read! Thx for preparing it.

So it seems to me that revealing the VM layout or SSP cookies is important
when we're attacking application which is operating with different set of
privileges or having access to different resources than the attacker has.
IMO it boils down to 2 basic cases

a). attacking a network/remote service
b). attacking a local service which is operating with different set of
privileges (a system service, a setuid binary)

Some of the presented ideas require ability to read output from
stdout/stderr, what limits the attack to set-uid binaries (or, to other
esoteric & and not-likely cases, like 644 stdout/stderr log files etc).
When set-uid application is executed libc is more "cautious" about printing
debug data, or accepting env-vars (like LIBC_FATAL_STDERR_).

So my point would be that some of those conditions required for successful
exploitation seem mutually-exclusive, e.g. you can try to attack/crash an
app with LIBC_FATAL_STDERR_, but it's ignored for set-uid apps, and I'm not
sure I'm seeing any other attack vector on privileged apps, unless I'm
missing sth.

Just wondering about your thoughts on that.

-- 
Robert Święcki

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists