When Ax1024 isn’t enough

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.


Plain life is just not random enough

While trying to generate a gpg keypair on a remote server, I discovered I lack entropy. Eventually I had to physically type on the keyboard in order to generate enough random bytes.
A short research led me to the following startling thread in the Linux kernel mailing list; Someone suggested to disable the entropy gathering from network cards: http://marc.theaimsgroup.com/?l=linux-kernel&m=114684809230875&w=2
* Note that in stock kernel version, entropy is still gathered from network cards.

I see this as an extremely bad move. ‘Headless’ servers with no keyboard and mouse have very few ways to create random entropy.
Web servers are an extreme example. There are few disk events that can contribute to the amount of entropy, and on the other hand SSL connection requires a lot of randomness.

This decision, if indeed accepted, is completely absurd. If someone decides to cancel network card as a source to random number generation, at least leave it as an option to the kernel module, a /proc entry or something. Why just diff it out??

To make things worse, Intel used to provide an onboard random number generator. This initiative was torpedoed, and the chip no longer exists in modern boards. There goes another source of random entropy out the window.

Modern day servers requires more sources of entropy than ever. We use VPNs, SSH and HTTPS. Let’s face it, SSL is ubiquitous.

As an example, try to run 4 simultaneous ssh connections to a dedicated web server (for some time, at least 4-5 hours), and try to generate a GPG keypair. 9 out of 10 times you’ll be out of entropy.

Suggested solutions like gathering entropy from the sound card don’t cut it for production servers.
There are the of course the dedicated PCI cards: http://www.broadcom.com/collateral/pb/5802-PB05-R.pdf

But then we could also ask for a Schrödinger’s cat that sits in a conveniently located alternate universe to establish SSL handshakes for us.

Attacks on PRNGs are well documented. Today no one believes that clock interrupts are cryptographically random. For example, look at: http://www.gutterman.net/publications/GuttermanPinkasReinman2006.pdf

I would love to hear your opinions and suggestions from security point of view.

Skype – The new NMAP?

In Blackhat Europe 2006 Philippe BIONDI presented his work on Skype.
Skype is famous for the level of obscurity taken to protect the code and protocol from prying eyes.

This outstanding work unveils Skype’s inner workings, reverse engineering the application and the network protocol and provides code samples.

The author poses and later answers three questions:

  1. Is Skype a backdoor?
  2. Can one detect and block Skype traffic?
  3. Is Skype safe enough for Business use?

Several security related issues are brought to light:

  • Several heap overflows were found during the research.
  • Skype can be DoSed by a single packet
  • Skype can be abused as anything from a port scanner to a botnet and covert channels in P2P

For the rest of this excellent work get the full paper at: