CSA-L03: Linux kernel vmsplice unchecked user-pointer dereference

2008-02-12 Thread Wojciech Purczynski
]=== Wojciech Purczynski [EMAIL PROTECTED] Wojciech Purczynski is a Security Researcher at Vulnerability Research Labs, COSEINC PTE Ltd. http://coseinc.com Wojciech Purczynski is also a member of iSEC Security Research http://isec.pl/ ===[ LEGAL DISCLAIMER

COSEINC Linux Advisory #2: IA32 System Call Emulation Vulnerability

2007-09-24 Thread Wojciech Purczynski
]== 18th September 2007 Vendor notification 24th September 2007 Public disclosure ===[ AUTHOR ]=== Wojciech Purczynski [EMAIL PROTECTED] Wojciech Purczynski is a Security Researcher at Vulnerability Research Labs

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-16 Thread Wojciech Purczynski
Could you please explain it to me where do you see privilege escalation here? Sending a signal to privileged process is a privilege itself. Under some circumstances this may lead to other consequences. For example I was able to code local root exploit using some very common suid binary,

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-15 Thread Wojciech Purczynski
This doesn't change anything in what I said previously. If the sender's EUID or RUID equals to any of SUID or RUID of the victim or the sender process is root, the sender can send any signal to the victim; if none of those conditions are met, it obviously can't, no matter how and what signal

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-15 Thread Wojciech Purczynski
In my eyes this is definitely a security issue. But I cannot imagine a way to exploit this issue at the moment. First you have to find a suid binary which fork()'s. Next thing is that you need access to that binary. And then? If both conditions are really met, what's next? The possibilities

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-15 Thread Wojciech Purczynski
In this case check_kill_permission() returns -EPERM for unprivileged parent. You always talked about setuid root process sending PDEATH_SIG to the root child, didn't you? check_kill_permission() checks current-euid and current-uid against t-uid and t-suid, where 'current' is the pointer

COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-14 Thread Wojciech Purczynski
]=== Wojciech Purczynski [EMAIL PROTECTED] Wojciech Purczynski is a Security Researcher at Vulnerability Research Labs, COSEINC PTE Ltd. Wojciech Purczynski is also a member of iSEC Security Research. ===[ LEGAL DISCLAIMER

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-14 Thread Wojciech Purczynski
Small correction - I forgot to add setuid(0) ;) PARENT CHILD fork() prctl(PR_SET_PDEATHSIG) execve(/bin/setuid-binary)

Re: COSEINC Linux Advisory #1: Linux Kernel Parent Process Death Signal Vulnerability

2007-08-14 Thread Wojciech Purczynski
I'm not sure this is a real security issue. If some process has the same effective UID as the given one, the former can always send any signal to the latter. Thus the behaviour you described is IMHO normal. It becomes a security issue whenever suid process drops user's UIDs.

ptrace/execve race condition exploit (non brute-force)

2001-03-27 Thread Wojciech Purczynski
] http://www.elzabsoft.pl/~wp | | +48604432981http://www.elzabsoft.pl/~wp/gpg.asc | +-+ /* * epcs v2 * ~~~ * exploit for execve/ptrace race condition in Linux kernel up to 2.2.18 * * (c) 2001 Wojciech Purczynski / cliph

Re: Memory leakage in ProFTPd leads to remote DoS (SIZE FTP); (Exploit Code)

2001-01-10 Thread Wojciech Purczynski
ug. I use proftpd-1.2.0rc2 on RH 6.2. Confirmed also on 1.2.0pre10. Cheers, wp +----+ | Wojciech Purczynski [EMAIL PROTECTED] http://www.elzabsoft.pl/~wp | | GSM: +48604432981 Linux Administrator SMS: [EMAIL PROTECTED] | +---