SHA gives a 160bit hash. Even assuming the algorithm is perfect, there will be collisions for anything over 160bits long. Even something the size of an mp3 (a couple megabytes) will likely have many, many collisions that are the same size.
It's extremely possible, the challenge is finding them.
If the length of the mem to copy is stored in a signed int, you can get an integer overflow that will let it pass your MAX_BUFFER_SIZE check and overflow the buffer. If you're dealing with strings, you should probably be checking for MAX_BUFFER_SIZE - 1, because a handful of string-related functinos (at least in C) like to copy the null terminator over as well.
The reason the hammer myth was considered debunked was because it didn't make enough of a difference. I haven't seen that show in a while, but if I remember correctly, dropping the hammer made something like 1g difference... and since that difference turned out to be 279g vs 280g at point of impact, it means essentially nothing since you'll be dead anyway.
This isn't a race condition with ptrace and execve, this is the kernel not handling threads properly with ptrace.
That being said, there are mitigating factors... packetstormsecurity.nl has a kernel module that disables ptrace for all users other than root (aptly named "ptracekm")... and users of grsecurity with randomized pids turned on should be safe as well, since the exploit assumes child = mypid+1
Slashdot Mirror
Okay, now explain why an insightful/informative post like that gets modded funny.
SHA gives a 160bit hash. Even assuming the algorithm is perfect, there will be collisions for anything over 160bits long. Even something the size of an mp3 (a couple megabytes) will likely have many, many collisions that are the same size.
It's extremely possible, the challenge is finding them.
I wonder if this means Slackware will drop back down to a single CD install.
Because we all know how dark, emotional and tragic PG13 movies are.
When the new features being written up are "hey look, a minor change to the desktop in the way window focus is handled!" is it even worth the story?
Now with no new exciting features!
Yes.
If the length of the mem to copy is stored in a signed int, you can get an integer overflow that will let it pass your MAX_BUFFER_SIZE check and overflow the buffer. If you're dealing with strings, you should probably be checking for MAX_BUFFER_SIZE - 1, because a handful of string-related functinos (at least in C) like to copy the null terminator over as well.
It says "http://slashdot.org/search.pl?topic=133" Please Drive Through
The reason the hammer myth was considered debunked was because it didn't make enough of a difference. I haven't seen that show in a while, but if I remember correctly, dropping the hammer made something like 1g difference... and since that difference turned out to be 279g vs 280g at point of impact, it means essentially nothing since you'll be dead anyway.
Talk about depth perception.
Don't tell me you've forgotten A/UX?
Raise awareness of a rediculous lawsuit (and maybe poke a bit of fun at kevin mitnick too) with a bumper sticker or a t-shirt design.
would you like to play a game?_
This isn't a race condition with ptrace and execve, this is the kernel not handling threads properly with ptrace.
... packetstormsecurity.nl has a kernel module that disables ptrace for all users other than root (aptly named "ptracekm") ... and users of grsecurity with randomized pids turned on should be safe as well, since the exploit assumes child = mypid+1
That being said, there are mitigating factors