| |||||||||||||
A nasty local kernel vulnerabilityA nasty local kernel vulnerabilityPosted Feb 26, 2013 12:29 UTC (Tue) by PaXTeam (subscriber, #24616)In reply to: A nasty local kernel vulnerability by dpquigl Parent article: A nasty local kernel vulnerability
> Is there something specific about this exploit that makes it that he only supports 3 of the distro kernels?
i guess you didn't read the README either :P
> mpougatsa_me_krema_kai_milko.tgz -- A trimmed down version of an old exploit for
or the code:
/* ...just in case you forgot the root password on your Fedora CPanel/Plesk ;) */
extra brownie points if you can find the right numbers for your kernel ;).
(Log in to post comments)
A nasty local kernel vulnerability Posted Feb 26, 2013 12:45 UTC (Tue) by dowdle (subscriber, #659) [Link]
It isn't called Fedora Core anymore. Just Fedora. Yeah, this probably isn't the right place for this but...
A nasty local kernel vulnerability Posted Feb 26, 2013 19:20 UTC (Tue) by dpquigl (subscriber, #52852) [Link]
So basically it was just made lame instead of detecting the addresses on its own. So if you took Brad's symbol location code from his released exploits and popped them into this you wouldn't need the kernel signatures as long as a system.map or kallsyms was detected.
A nasty local kernel vulnerability Posted Feb 26, 2013 21:53 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
exactly. try to convince him to update enlightenment that hasn't seen one in a while as this bug's like the perfect candidate :).
A nasty local kernel vulnerability Posted Feb 27, 2013 19:47 UTC (Wed) by dpquigl (subscriber, #52852) [Link]
For those who want to try out the exploit on a vm or something You can add a line similar to this into that targets array in main.c.
{"My Kernel", 57, VOIDP(<addr of perpare_kernel_cred>), VOIDP(<addr of commit_creds>)}
I haven't read through the entire exploit so the 57 may need to be changed to something else but it might not need to be since it stays the same across kernel versions.
Also to get the addresses of prepare_kernel_cred and commit_creds just grep those symbols in your System.map under boot. Example: grep prepare_kernel_cred /boot/System.map.mykernel
Assuming the code in shellcode.c is the only shellcode being used (which once again I haven't read it all) it appears to change the creds structure of the running process. It does this by calling the function pointer they have to perpare_kernel_cred (kernel/cred.c) with NULL which will use the init cred which has a UID and GID of 0. It then uses the commit_creds function pointer it has with the new root creds structure to set the creds of the process to root.
I'm not about to run the exploit on my work machine so I'm not sure if the line I gave above will work 100% but its a start. This is what PaXTeam was getting at with his response to the other guy claiming you're safe if the exploit didn't print out a certain message. The exploitable bug may still be in your kernel. The issue is that the two magic numbers for function addresses weren't right. BTW you have the potential of kernel oopsing your box if you run the exploit with bad addresses and you happen to hit pages you shouldn't be touching.
This is the difference between an exploitable bug and a weaponized exploit. The bug is still there and just because this implementation/POC didn't work on your machine doesn't mean you're not vulnerable. PaXTeam and Brad may be harsh with their words but this is a very important point to get. Just because this example didn't work on your box doesn't mean you're not vulnerable. This could have just as easily have been written to scan kallsyms or a system.map based on information from uname to pull those addresses and work.
|
|||||||||||||