Borge Ousland and the unexpected
I was asked by a reporter today from USA Today what the average person can do to protect themselves from all of the security problems (identity theft, phishing, hackers, etc.) that are increasingly a fact of modern life. I gave the usual answer (likely many of you do the same thing with family & friends) that people should get XP SP2, turn on AV, ICF and autoupdates. I was thinking after the conversation, that I should really think of a better answer for this question, because I get asked it all the time. On a related note (you'll see the relation here in a minute), I went and saw Borge Ousland last night at the Field Museum in Chicago. Borge is a polar explorer, who has made a name for himself by completing some of the most intense solo unsupported (meaning no help from outsiders, no helocopters, no dog sleds, etc.). On his most difficult journey to ski across the North Pole from Russia to Canada, (note: this means in some cases swimming between breaks in pack ice, and losing about 60 of 150 lbs in body weight!) he encountered something quite unexpected at the geographic North Pole. Some shiek from a middle eastern country had flown up to the North Pole in a helocopter for the afternoon, and was walking around on the ice taking pictures in his tunic. This was the half way point for Borge, and he by no means expected to find a tourist walking around taking pictures, much less an guy in a tunic!
In order to have effective security, no matter what it is for (nuclear weapons, banking web servers, your home computer), you have to expect the unexpected. It doesn't mean you need to be paranoid. You should always realize that you are a target, and take appropriate steps. Lets take a couple of examples.
First is the old GDI+ vulnerability. If you aren't familiar with it, basiclly the GDI+ library is vulnerable to a heap overflow when it is parsing .jpg image files. The .jpg file standard allows for a comment section (COM) that will contains the length of the comment as well as the comment itself. The vulnerable GDI+ library expects that after finding the comment tag (COM) it will always be given some size, because the comment size field itself takes up 2 bytes. So, GDI+ always subtract 2 bytes in size from the length of the comment field to remove the space the comment size field takes up. But... what if a clever person puts a size of 1 or 0? GDI+ will subtract the 2, giving us a negative number, which ends up being a large positive number. This results in a classic integer overflow. Ok, so there you have it, the developer did not do as expected and check for some crafty hacker manually creating a .jpg with a comment size of 0 or 1. Let's take this further. Now that we know about the vulnerability we can either fix the problem by patching, or attempt to allow antivirus or network IDS to do the work for us by detecting any comment in a .jpg file with size 1 or 0.
In other news, a quick update to the whole T-Mobile situation. My blog was featured on Slashdot, PC World, and recived about a 400 links from other bloggers. This was kind of fun, it resulted in about 100k unique vistors over a one week period. I was also contacted by some person who sent me an "exploit" for the T-Mobile login page. Im not going to post it here, but if you want to check it out, I will email it to you. I've now learned that it has also been posted elsewhere as well.
In order to have effective security, no matter what it is for (nuclear weapons, banking web servers, your home computer), you have to expect the unexpected. It doesn't mean you need to be paranoid. You should always realize that you are a target, and take appropriate steps. Lets take a couple of examples.
First is the old GDI+ vulnerability. If you aren't familiar with it, basiclly the GDI+ library is vulnerable to a heap overflow when it is parsing .jpg image files. The .jpg file standard allows for a comment section (COM) that will contains the length of the comment as well as the comment itself. The vulnerable GDI+ library expects that after finding the comment tag (COM) it will always be given some size, because the comment size field itself takes up 2 bytes. So, GDI+ always subtract 2 bytes in size from the length of the comment field to remove the space the comment size field takes up. But... what if a clever person puts a size of 1 or 0? GDI+ will subtract the 2, giving us a negative number, which ends up being a large positive number. This results in a classic integer overflow. Ok, so there you have it, the developer did not do as expected and check for some crafty hacker manually creating a .jpg with a comment size of 0 or 1. Let's take this further. Now that we know about the vulnerability we can either fix the problem by patching, or attempt to allow antivirus or network IDS to do the work for us by detecting any comment in a .jpg file with size 1 or 0.
In other news, a quick update to the whole T-Mobile situation. My blog was featured on Slashdot, PC World, and recived about a 400 links from other bloggers. This was kind of fun, it resulted in about 100k unique vistors over a one week period. I was also contacted by some person who sent me an "exploit" for the T-Mobile login page. Im not going to post it here, but if you want to check it out, I will email it to you. I've now learned that it has also been posted elsewhere as well.
