Re: [gentoo-hardened] Interesting: CVE-2012-0056

[Tóth Attila]

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, [phone]

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
>
>