On 24 Jan 2012 at 2:35, Francesco R.(vivo) wrote:

> BTW this in "vanilla" gentoo does not work because of the permission of the su
> file:
> ls -l /usr/bin/su
> -rws--x--x 1 root root 36776 18 gen 21.31 /usr/bin/su
>
> readelf cannot read the address, but there can be other ways to access the
> binary for example for group "disk"

http://seclists.org/fulldisclosure/2012/Jan/396

> hardened gentoo is un-affected as expected (but you already know)

this is not quite true, what could work against grsec is an exploit that
implemented a ret2libc style exploit coupled with bruteforcing (if the
target suid is a PIE). i hope you're all enabling the bruteforce protection
feature in grsec .

2012.Január 24.(K) 02:35 idÅ‘pontban Francesco R.(vivo) ezt Ã*rta:
> On Tuesday 24 January 2012 00:49:19 Tóth Attila wrote:
>> Please take a look at on this exploit:
>> http://blog.zx2c4.com/749
>> It is interesting to think about /proc/pid/mem protection and about
>> building su with PIE enabled...
>>
>> Regards:
>> Dw.
>
> BTW this in "vanilla" gentoo does not work because of the permission of
> the su
> file:
> ls -l /usr/bin/su
> -rws--x--x 1 root root 36776 18 gen 21.31 /usr/bin/su
>
> readelf cannot read the address, but there can be other ways to access the
> binary for example for group "disk"
>
> hardened gentoo is un-affected as expected (but you already know)
>

So this exploit is a good example on why hardened gentoo is beneficial.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 24.(K) 08:26 idÅ‘pontban pageexec@freemail.hu ezt Ã*rta:
> On 24 Jan 2012 at 2:35, Francesco R.(vivo) wrote:
>
>> BTW this in "vanilla" gentoo does not work because of the permission of
>> the su
>> file:
>> ls -l /usr/bin/su
>> -rws--x--x 1 root root 36776 18 gen 21.31 /usr/bin/su
>>
>> readelf cannot read the address, but there can be other ways to access
>> the
>> binary for example for group "disk"
>
> http://seclists.org/fulldisclosure/2012/Jan/396
>
>> hardened gentoo is un-affected as expected (but you already know)
>
> this is not quite true, what could work against grsec is an exploit that
> implemented a ret2libc style exploit coupled with bruteforcing (if the
> target suid is a PIE). i hope you're all enabling the bruteforce
> protection
> feature in grsec .

My only concern against bruteforce protection is the possiblity of a DoS.
But it's always better to get DoSed, than to get bruteforced...
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

On Tue, 24 Jan 2012 09:33:36 +0100
"Tóth Attila" wrote:

> My only concern against bruteforce protection is the possiblity of a DoS.
> But it's always better to get DoSed, than to get bruteforced...

Is ptrace disabled on hardened gentoo too?

--
Kc

El 24/01/12 12:52, Kevin Chadwick escribió:
> On Tue, 24 Jan 2012 09:33:36 +0100
> "Tóth Attila" wrote:
>
>> My only concern against bruteforce protection is the possiblity of a DoS.
>> But it's always better to get DoSed, than to get bruteforced...
> Is ptrace disabled on hardened gentoo too?
>
No, but it is enforced.

1.)
If you happen to use grsecurity, you have two kernel options for
controlling ptrace:
GRKERNSEC_AUDIT_PTRACE "Ptrace logging"
If you say Y here, all attempts to attach to a process via ptrace
will be logged. If the sysctl option is enabled, a sysctl option
with name "audit_ptrace" is created.

GRKERNSEC_HARDEN_PTRACE "Deter ptrace-based process snooping"
If you say Y here, TTY sniffers and other malicious monitoring
programs implemented through ptrace will be defeated. If you
have been using the RBAC system, this option has already been
enabled for several years for all users, with the ability to make
fine-grained exceptions.

This option only affects the ability of non-root users to ptrace
processes that are not a descendent of the ptracing process.
This means that strace ./binary and gdb ./binary will still work,
but attaching to arbitrary processes will not. If the sysctl
option is enabled, a sysctl option with name "harden_ptrace" is
created.

2.)
Moreover, in the policy file with enabled RBAC, you can select which
process can ptrace:
-CAP_ALL
+CAP_SYS_PTRACE

3.)
And even some more options:
# Role flags:
# A -> This role is an administrative role, thus it has special privilege
normal
# roles do not have. In particular, this role bypasses the
# additional ptrace restrictions

object:
# p -> reject all ptraces to this object

process:
# t -> allow this process to ptrace any process (use with caution)
# r -> relax ptrace restrictions (allows process to ptrace processes

So it depends on what kind of hardening method you are using.

Rearding the actual exploit:
1.)
GRKERNSEC_PROC_MEMMAP "Remove addresses from /proc/<pid>/[smaps|maps|stat]"
If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat
files will
give no information about the addresses of its mappings if
PaX features that rely on random addresses are enabled on the task.
If you use PaX it is greatly recommended that you say Y here as it
closes up a hole that makes the full ASLR useless for suid
binaries.

2.)
readelf -h /bin/su
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x2010
Start of program headers: 52 (bytes into file)
Start of section headers: 33572 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24

Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 24.(K) 12:52 idÅ‘pontban Kevin Chadwick ezt Ã*rta:
> On Tue, 24 Jan 2012 09:33:36 +0100
> "Tóth Attila" wrote:
>
>> My only concern against bruteforce protection is the possiblity of a
>> DoS.
>> But it's always better to get DoSed, than to get bruteforced...
>
> Is ptrace disabled on hardened gentoo too?
>
> --
> Kc
>
>