[REVS] Advanced Exploitation in Exec-Shield (Fedora Core Case Study)



The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Advanced Exploitation in Exec-Shield (Fedora Core Case Study)
------------------------------------------------------------------------


SUMMARY

The below linked paper discusses some technique to attack applications on
exec-shield kernel found in the Fedora Core operating system.

DETAILS

2 - Brief features of Fedora Core system (gcc + glibc + exec-shield)
Fedora Core is a project run by Redhat and it provides technical
background. Fedora Core (F/C since now), unlike old RedHat OS, has stack
and heap hacking prevent system called exec-shield. Exec-shield makes its
specialty of blocking all the existing attacks concern stack, buffer,
function pointer overflow and overwriting data structure or injecting code
on that data structure. You can find more by looking ANNOUNCE-exec-shield
on Reference 7.16

2.1 - non-executable randomization stack, malloc heap, randomization
library
Stack and data area, heap area allocated by malloc() function are now
non-executable, and it makes classic shellcode useless. Area that library
is mapped ,merely, has execute privilege. But even this will be re-mapped
on every single execution. This randomizing algorithm ,unlike that of
Redhat Linux 9.0, is very unpredictable. It looks very similar to Openwall
Project (7.12) of Solar Designer and PaX kernel system (7.13)

2.2 - Addressing system under 16mb (NULL pointer dereference protection)
Kernel re-maps all PROT_EXEC mapping in ascii-armor area and make its
address system less than 16mb. This idea came from the fact that hackers
use 4byte library address when they make overflow attempt on old 32bit
system. By doing this, memory address now has null in the address it means
many memory related hacking technique such as return-into-libc(7.2) are
now hard to be used. Sometimes, there is a chance to enter null into
overflowed buffer easily. But on this paper, dong-hun is not going to talk
about this.

In addition, recent changes on glibc make some library function address
end with null or 0x20.

2.3 - PIE technology (changed gcc)
PIE stands for Position Independent Executables is a similar concept with
old PIC. This is a way to protect application from being exploited by
attacks such as buffer overflow.

2.4 - Changed method of accessing function parameter (changed glibc)
F/C 3 has glibc 2.3.3 on it. This glibc handles the commands that passed
into system() and exec family function with %ebp register. With the stack
overflow happening, hacker can manipulate %ebp register, so there is still
a good chance to indicate certain command to execute.


ADDITIONAL INFORMATION

The information has been provided by <mailto:xploit@xxxxxxxxxxxxxx>
dong-hun you.
The original article can be found at:
<http://x82.inetcop.org/h0me/papers/FC_exploit/FC_exploit.txt>
http://x82.inetcop.org/h0me/papers/FC_exploit/FC_exploit.txt



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages