I have seen two exploits so far for the NZB overflow, both on milw0rm (here and here). I took a look at the code and they do not look very reliable, in fact both of them suffer from the same problem I initially had when exploiting the bug.
The exploits on milw0rm are tuned for very specific environments, this is caused by the fact that Grabit prepends the current directory to the string copied in the buffer. The authors created the NZB exploits in a specific directory and the exploits will not work if they place it in another one with a different path length (this is why the second exploit has two 'targets').
When I was creating an exploit, this seemed like a serious problem for exploit reliability to me. But when tracing through the code, you will notice that the directory is not always prepended. If the DTD reference is to an absolute path (instead of a relative one), it will not prepend the directory and exploitation is a lot more reliable. After I fixed this in the two exploits, they work just fine on my system.
Thursday, May 7, 2009
Subscribe to:
Post Comments (Atom)
2 comments:
Your saying the exploit isn't 'reliable' because if the user installs GrabIt in a different directory (unlikely at best), they will fail? That is more of a unexpected situation than a reliability issue. Nice research, though. I didn't dig that deep; I just know mine should work on 99% of configurations =)
Hi Jeremy,
Well actually it's not the directory GrabIt is installed in that matters. It's the directory the NZB ends up in. So if I put exploit.nzb in C:\mynzbs\ what will be copied into the buffer is "C:\mynzbs\[dtdreference]", so in a directory with a different path length the exploit won't work.
Cheers,
Niels
Post a Comment