Recently, h07 published a vulnerability in Easy File Sharing FTP Server. Apparently a simple buffer overflow in the PASS command. This vulnerability is a nice example where fuzzing won’t cut it.
But the catch in the vulnerability is a comma. Only passwords starting with a comma (0x2c) can be overflowed. Why is this so important?
A fuzzer will usually take a legal FTP session, and will try to overflow interesting sections. The password field is a prime candidate, but the problem is, if you test for a simple overflow you’ll just send many ‘A’ characters or something similar. This is because fuzzers tend to look for the coin under the street-light.
Fuzzers today are sophisticated enough to look for many different types of programmer errors, but will usually look for the poster-child of each. For example, to find a format string, just send many %x. This is not done due to programmer lazyness, this is due to the sheer amount of possibilities to check. FTP is a relatively simple protocol, but with vendor extensions it has dozens of commands. Checking every command for vulnerabilities could take a long time, and with network considirations we’re talking weeks and months of continous bombardment on the target server.
joanna just published a blog entry on this issue, and how her poc doesn’t work on the new vista release.
“it quickly turned out that our exploit doesn’t work anymore! the
reason: vista rc2 now blocks write-access to raw disk sectors for user
mode applications, even if they are executed with elevated administrative
(hat tip to elad efrat)
Another long night, :sigh:
Creativeness is the name of the game,
in the end if you shave another byte or two, it’s not a big deal, (as much fun as it is, don’t get me wrong) you have to come up with better ideas. Sometimes, you are sure that what you got something good, but then you have to push your limits, and come up with something better.
I wish to thank Peter Ferrie, Nicolas Brulez and Jamz Yaneza for encouraging me and providing some information, about that downloader virus which is known to be around 330 bytes…
I haven’t got any sample of it, nor I know the real size, but to be sure my Tiny PE is smaller, my latest version stands at 304 bytes. If you read carefully my first blog post about this Tiny PE, I said that I was playing with Optional Header Size. So this time I cut a big part of it, and managed to crunch my code even more and put the Import Module Descriptor inside the header itself 🙂 Though, now I think I broke compatibility with other versions of Windows…
Who is going to get it to below 300 bytes? hehe.
You can find the latest Tiny PE here: tiny3.exe.
If you like Assembly, or you just happen to remember hex code by heart,
even something easy like: EB 02 13 37 33 C0 40 C3 (LOL – sad but true), then you should subscribe to our new code crunchers mailing list at http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers !
Have a beautiful weekend,
The Code-Crunchers mailing list has just been established.
Got an asm trick? Got a cool code crunching thingie going? Want to help crunch things further with others?
Just saw the most amazing exploit?
This is the place.
Open to anyone, not directly security related. To subscribe:
Reference, Tiny PE: http://blogs.securiteam.com/index.php/archives/675