atoth at atoth
Jan 24, 2012, 8:45 AM
Post #8 of 8
(523 views)
Permalink
|
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
>
>
|
signature.asc
