Mailing List Archive

On 25 Mar 2013 at 9:01, Kfir Lavi wrote:

> Hi,
> I'm looking for a way to reduce glibc code size.
> It can be a way to make system smaller and minimize the impact
> of attack vectors in glibc, as in return-to-libc attack.

study this and draw your conclusions whether the whole exercise is
worth it or not:

https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy

On 25/03/13 13:52, PaX Team wrote:
> On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
>
>> Hi,
>> I'm looking for a way to reduce glibc code size.
>> It can be a way to make system smaller and minimize the impact
>> of attack vectors in glibc, as in return-to-libc attack.
>
> study this and draw your conclusions whether the whole exercise is
> worth it or not:
>
> https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
>
>

This paper seems interesting against Return oriented programming:

http://www.cs.jhu.edu/~s/teaching/cs460/2012-fall/ROPdefender.pdf

Is gentoo-hardened better regarding the amount of unrandomized code
compared to other distros?
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Március 25.(H) 13:52 időpontban PaX Team ezt írta:
> On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
>
>> Hi,
>> I'm looking for a way to reduce glibc code size.
>> It can be a way to make system smaller and minimize the impact
>> of attack vectors in glibc, as in return-to-libc attack.
>
> study this and draw your conclusions whether the whole exercise is
> worth it or not:
>
> https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
>
>

On Mon, Mar 25, 2013 at 2:52 PM, PaX Team <pageexec@freemail.hu> wrote:
> On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
>
>> Hi,
>> I'm looking for a way to reduce glibc code size.
>> It can be a way to make system smaller and minimize the impact
>> of attack vectors in glibc, as in return-to-libc attack.
>
> study this and draw your conclusions whether the whole exercise is
> worth it or not:
>
> https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
>
>
Thanks for sharing this talk. I didn't know that the program image in
Linux is not randomize by ASLR.
What i understand from this talk: I can probably take a lot of code
out of glibc, but it will never be less then 20K, which lets attacker
that is able to jump to glibc, to construct his ROP program.
As I don't have much experience in security, my question would be: Can
we deploy another mechanism to fight this ROP program building from
the program image?

Thanks,
Kfir

On 25 Mar 2013 at 22:35, Kfir Lavi wrote:

> Thanks for sharing this talk. I didn't know that the program image in
> Linux is not randomize by ASLR.

well, that's not quite true these days, even vanilla has logic to
randomize the main executable - provided it's a PIE. it of course
depends on the distros to provide PIEs for some/most of the programs
they distribute, which is where the main difference is between say
hardened gentoo and regular mainstream distros (the other difference
is the amount of randomization due to PaX).

> What i understand from this talk: I can probably take a lot of code
> out of glibc, but it will never be less then 20K, which lets attacker
> that is able to jump to glibc, to construct his ROP program.

exactly.

> As I don't have much experience in security, my question would be: Can
> we deploy another mechanism to fight this ROP program building from
> the program image?

as i said above, PIE is one approach if we ignore infoleaking bugs
that make all randomization based solutions fail. the real solution
is some form of control flow enforcement but as far as i know,
nobody proposed (let alone produced) a sufficiently well performing
and easy-to-deploy idea so far. this is a very hot research topic,
both in academia and industry, just look up microsoft's bluehat prize
a year or so ago.

Normally you should have build nearly everything with PIE (there is a
nifty but a little bit outdated script called checksec.sh) - on my
system (Desktop with KDE right now) every running process has PIE
enabled.
You can enable and disable it via gcc-config (there are nopie and nopic
and vanilla compiler profiles (which seem to be incompatible with gcc 4.8) PIC and PIE enabled is the default though)

WKR
Hinnerk

On Mon, Mar 25, 2013 at 07:00:15PM +0100, "Tóth Attila" wrote:
> Is gentoo-hardened better regarding the amount of unrandomized code
> compared to other distros?
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
> 2013.Március 25.(H) 13:52 időpontban PaX Team ezt írta:
> > On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
> >
> >> Hi,
> >> I'm looking for a way to reduce glibc code size.
> >> It can be a way to make system smaller and minimize the impact
> >> of attack vectors in glibc, as in return-to-libc attack.
> >
> > study this and draw your conclusions whether the whole exercise is
> > worth it or not:
> >
> > https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
> >
> >
>
>
>

PIE is used in hardened gentoo, If PIE can't protect you against this,
ssp at least could try to do it, this is the reason because
-fstack-protector-all and -D_FORTIFY_SOURCE=2 are needed, and at least
-fstack-protector-all is really extended in hardened gentoo.. as
another security layer. .

2013/3/25, "Tóth Attila" <atoth@atoth.sote.hu>:
> Is gentoo-hardened better regarding the amount of unrandomized code
> compared to other distros?
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
> 2013.Március 25.(H) 13:52 időpontban PaX Team ezt írta:
>> On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
>>
>>> Hi,
>>> I'm looking for a way to reduce glibc code size.
>>> It can be a way to make system smaller and minimize the impact
>>> of attack vectors in glibc, as in return-to-libc attack.
>>
>> study this and draw your conclusions whether the whole exercise is
>> worth it or not:
>>
>> https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
>>
>>
>
>
>
>

I'm just thinking aloud here...
So as long as hardened gcc is used to compile the code, it makes the
exploitation harder compared to distros not pushing PIE as much. I think
other distros also acknowledged the importance of PIE, as well in the mean
time:
https://wiki.ubuntu.com/Security/Features#Built_as_PIE
http://wiki.debian.org/Hardening#gcc_-pie_-fPIE
For a userland like that, binaries compiled without the hardened toolchain
are the easiest to exploit. Binary packages, third-party binaries,
closed-source binaries. These software are usually important executables
way over 20k.

I wonder how these ROP techniques can theoretically perform in a java
virtual machine? What are the possbile target vectors for Python or Ruby?
What about JIT code?
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Március 26.(K) 10:18 időpontban Javier Juan Martínez Cabezón ezt írta:
> PIE is used in hardened gentoo, If PIE can't protect you against this,
> ssp at least could try to do it, this is the reason because
> -fstack-protector-all and -D_FORTIFY_SOURCE=2 are needed, and at least
> -fstack-protector-all is really extended in hardened gentoo.. as
> another security layer. .
>
> 2013/3/25, "Tóth Attila" <atoth@atoth.sote.hu>:
>> Is gentoo-hardened better regarding the amount of unrandomized code
>> compared to other distros?
>> --
>> dr Tóth Attila, Radiológus, 06-20-825-8057
>> Attila Toth MD, Radiologist, +36-20-825-8057
>>
>> 2013.Március 25.(H) 13:52 időpontban PaX Team ezt írta:
>>> On 25 Mar 2013 at 9:01, Kfir Lavi wrote:
>>>
>>>> Hi,
>>>> I'm looking for a way to reduce glibc code size.
>>>> It can be a way to make system smaller and minimize the impact
>>>> of attack vectors in glibc, as in return-to-libc attack.
>>>
>>> study this and draw your conclusions whether the whole exercise is
>>> worth it or not:
>>>
>>> https://www.usenix.org/conference/usenix-security-11/q-exploit-hardening-made-easy
>>>
>>>
>>
>>
>>
>>
>
>

On 26/03/13 16:11, "Tóth Attila" wrote:

>
> I wonder how these ROP techniques can theoretically perform in a
> java virtual machine? What are the possbile target vectors for
> Python or Ruby? What about JIT code?

http://www.grant-olson.net/python/pyasm

On 26/03/13 16:45, Javier Juan Martínez Cabezón wrote:
> On 26/03/13 16:11, "Tóth Attila" wrote:
>
>>
>> I wonder how these ROP techniques can theoretically perform in a
>> java virtual machine? What are the possbile target vectors for
>> Python or Ruby? What about JIT code?
>
> http://www.grant-olson.net/python/pyasm
I'm not sure if I understood you wrongly, do you want mean how can
someone do ROP in python? or how a python script could be objetive of a
ROP attack?

Python is linked against libc too, and finally it finish being executed
in machine (assembler) code, the main difference is that C for example
needs compilation, python scripts "are compiled" on the fly.

2013.Március 26.(K) 16:56 időpontban Javier Juan Martínez Cabezón ezt írta:
> On 26/03/13 16:45, Javier Juan Martínez Cabezón wrote:
>> On 26/03/13 16:11, "Tóth Attila" wrote:
>>
>>>
>>> I wonder how these ROP techniques can theoretically perform in a
>>> java virtual machine? What are the possbile target vectors for
>>> Python or Ruby? What about JIT code?
>>
>> http://www.grant-olson.net/python/pyasm
> I'm not sure if I understood you wrongly, do you want mean how can
> someone do ROP in python? or how a python script could be objetive of a
> ROP attack?

I ment: how to do ROP in python and how a compiled python script can be an
objective of a ROP attack? If the attacker carefuly studies the way how
exactly the script becomes executable code in memory, it gains control on
a mechanism to plant the necessary pre-designed snippets needed for the
actual exploit.
We saw the exploit hardening software of the guy in the presentation
video. If they can succesfully analyse given language like java or python,
they could find a way to pre-create the code fragments they need. There
could be an additional phase for designing and implanting these. If the
runtime environment has a flaw, they may gain full or partial control over
the location as well. So that means less probing would be necessary and
the mechanism would be much faster.

> Python is linked against libc too, and finally it finish being executed
> in machine (assembler) code, the main difference is that C for example
> needs compilation, python scripts "are compiled" on the fly.

I could also mention other languages, like python. Those who deal with
scripts or partially compiled interim formats. I don't have internal
information about these. But I suspect that address randomization of the
run-time generated code was not considered as a focus of interest. There
can be numerous weaknesses (even by design) in such languages. If the
attacker figures out the way to get through the execution process, there
will be endless victims out there to exploit.

I'm not a professional computer scientist, so I'm sorry if I use some tech
words inappropriately.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

On Tue, 26 Mar 2013 19:45:39 +0100
"Tóth Attila" <atoth@atoth.sote.hu> wrote:

> I ment: how to do ROP in python and how a compiled python script can be an
> objective of a ROP attack? If the attacker carefuly studies the way how
> exactly the script becomes executable code in memory, it gains control on
> a mechanism to plant the necessary pre-designed snippets needed for the
> actual exploit.

ROP-based exploitation requires the attacker to have exact knowledge
about content and layout of the bytecode (which contains
potential ROP gadgets) in memory, ability to store arbitrary data at
some known or appropriate location and ability to purposefully affect
execution flow (in cases when the natural execution flow won't
"execute" the payload eventually). With those requirements met, it
should be much easier to store some raw bytecode (or source code, in
case of pure interpreters) somewhere and then make it interpreted by
the language runtime.