Xblog

So starting with the outer bits of the code first, it is pretty clear that the bulk of the message is escaped Javascript which is fed in to eval. Not exactly a good sign, but not necessarily a bad thing. The first step I took was to unescape the relevant data (without performing the eval of course), which yielded this.

The source was clearly obfuscated, so I went through it, cleaned up the formatting and attempted to assign more meaningful names to variables and functions. This yielded this. The transform1 function included a use of eval(someString.replace(/blah/, ”)), which was clearly just a way of obfuscating how myCallee was computed, so I performed the replace and substituted the result, yielding this much clearer source, which shows that myCallee is actually the function itself!

So, it now becomes clear that the obfuscation of transform1 was not entirely random in nature, as the source itself was used as part of the key to decode the “payload” (the string passed in to transform1 after its definition). The easiest way to accurately decode this was to create both the original fpTu function in all its obfuscated glory, then set myCallee to fpTu in transform1, and then see what we got back from transform1 when we passed it the payload.

Not surprisingly, we have another somewhat obfuscated chunk of Javascript. After reformatting it (thank you Steve Yegge for js2-mode and providing some more meaningful function and variable names, the payload now looks like this.

There are still a bunch of places where the replace(/blah/, ”) idiom is being used to obfuscate things, and another place where a variant is used where all alphanumeric values are being replaced with a period, and then all instances of multiple periods are replaced with a single one. After unraveling those, the intent of the code becomes clear and we can attach more meaningful names to the functions and variables. Thus I ended up with this.

We can now see that the code points to 3traff.cn (don’t you feel safer already? ;-), and it cleverly embeds an iframe pointing to 3traff.cn in to each document as it is loaded. I’m not up on my browser exploits, but it looks like the intent of all this is to at the very least track users as they go off site, and also might be hoping to confuse a browser about which domain a document came from, and therefore potentially cause cookies to leak to 3traff. Either way, this isn’t the kind of code I like running in my browser.

During interviews, I always hate getting the question “Why did you become a software developer?”, because to me it’s like asking, “Why did you become a heterosexual male?”. I’m sure there are factors, both genetic and environmental, but I can’t claim to have any real understanding of them. So, when I got this kind of question early on, I would fib a bit and tell people it was because my name had gotten me mixed up in who knows how many databases, and I wanted to fix that.

There is some truth to it. When I was in grade school I missed two days of school because I was sick, but because there was another boy with the same name attending school with me, all the records showed me as present, and I was called in to the Dean’s office because he had noticed I wasn’t in his class, and he assumed I was had skipped out on his class. I once had all my Physics grades disappear because they overlapped with grades for another Christopher Smith. When I was at MIT (of all places), I was the source of much drama during rush week, because frats are obligated to tell other frats if a potential pledge is with them (imagine the confusion with multiple Chris Smith’s, sometimes at the same place, sometimes at different places). My French teacher in high school had the unfortunate case of six students named Chris in a class of twenty-two. She decided to name use “Christophe Un, Christophe Duex…”, <sarcasm> which in no way made us feel like weren’t getting individual attention </sarcasm>. I remember thinking my title as “Christophe Cinq” was a likely indication of how little she liked me, particularly since “Christophe Six” had showed up a month in to the school year. When I was in boarding school, my parents arrived for the end of my first year, and my mother ran in to who she thought was my math teacher (in fact, he’d been my teacher for the first week of school before I transferred to a different class) and almost fainted when he said my impressive performance on the final exam had “really made a difference” (my mom had correctly been under the impression that I was an A math student before I took the final). When I first visited the financial aid office in university, I felt quite the ego stroke as I was mistaken for a grad student with the same name but five years my senior. While flattering, I think it took most of the first semester to straighten out my financial aid status. In a recent election, I discovered a small flaw in the voting process: my name had been crossed off for another Christopher Smith in the same precinct. I had to write up a provisional ballot, and to this day I doubt that my votes were counted. Most embarrassing was probably when I was invited to an orientation seminar for new students on campus that was clearly intended for women (if I’d been less insecure I would have realized it was a terrific opportunity to find a date, but somehow the emasculating experience of being mistaken for a female removed whatever limited confidence I had). I think my favourite one though was when I found out how much more a product manager with my name made when a notice of a raise got routed the wrong way.

I could probably drum up a half dozen more stories, but suffice it to say, it has been an adventure walking through life with name disturbingly common amongst my peer group, and I certainly have become sensitive to issues of referential integrity and unique identifiers as a consequence (my wife remembers from a recent discussion of how the grading system worked at her school ;-). I find that most databases have far more logical constraints in them than the actual system they are trying to represent. I’m sure the personal angst from this has helped me at various points, but I think the biggest lesson I’ve learned from that is how most systems tend to have cases that fall through the cracks, and the need to identify and respond to this as best one can. Reading this article, the SSA gets a big fail from me.

With something as significant as whether a person is alive or not, corrections should be trivial. Listing someone as dead should come from a death certificate, which in turn should be tied to all kinds of personal identifiers, including name, SSN, date of birth, time of death, place of birth, etc., and the identifier for the death certificate should be tied in to the transaction that lists them as “dead” (of course, that only works if your system actually collects this information, but the fact that it doesn’t strikes me as insane). If someone challenges the notion that they are dead, it ought to be as simple as comparing the data in their death certificate against other data on record, and quickly reversing the operation in the case where it doesn’t add up (even better would be if the system notified those doing the data entry of a likely error at the time of entry). Sure there are errors in death certificates too, but it is probably pretty easy to determine that there was someone else who should have been marked dead, and this person was just collateral damage. Just name, date and place of birth ought to avoid collisions except in the most exception circumstance. Only the most exceptional cases would require significant review or effort on behalf of the “deceased” party. The system should also have an additional state between “deceased” and “alive” along the lines of “under review”. Sure, you might not hand out social security cheques to folks in that state, but you probably wouldn’t throw out their tax returns either.

Honestly, given how error prone and time consuming the system is, I have to wonder at the thinking which lead the powers that be to not streamline the process as I suggest long ago. I’m sure it makes sense in some really unfortunate way, but really, this is the kind of problem that you imagine happens somewhere else.

The install was pretty straight forward until a message appeared indicating that Trend Micro needed a software update that “optimized performance” be installed on my Vista system before it could itself install. Then a dialog popped up asking me if I’d like to install the hotfix for KB931365. Unlike on this blog there was no link to get more information on the hotfix, and of course the installer had helpfully suggested that all windows and all additional software be shut down during the install, so if this was your only computer, you were kind of SOL for uncovering what KB93165 was before approving the install.

Fortunately, I had other computers from which to look this kind of thing up, and from that I learned what those of you who followed the above link already know: this wasn’t just some performance fix, it was a fix for a BSOD, and would be triggered by the install of any anti-virus filter driver!

But wait, it gets better: the hotfix for this has been around in its present form since March 2007, and it looks like it first appeared at least as far back as January. Microsoft’s regular security update rounds have yet to include a fix for this.

The implications seem clear to me: either Microsoft doesn’t have much confidence in this fix or they don’t feel installing anti-virus software on Vista is important… most likely both. This is a bug that literally crashes a computer when installing software everyone should be installing… and yet they haven’t been able to roll out a long term fix after 10+ months? Please.

Here’s looking to see if it makes SP1.

So, one of the things I thought would be fun about using Safari on Windows is I could see what the web looks like from a loyal Mac user’s perspective (I empahsize loyal, because as far as I can tell most Mac users just use Firefox or Camino).

So, for starers, you gateway to the web is a massive promo page for Apple and Apple partners. I hope the people behind this stick to criticising Yahoo’s home page on aesthetic grounds only. Anyway, at the top of the page was a link to Celebrating the Best in Mac Software. Well, how could I not check out all the great software I was missing out on by not owning a Mac?

That’ when it got interseting. So, their highlighted category is “Leopard Application”, of course. Interestingly, neither winner nor runner-up got a web link. How odd. Anyway, going to the “developer” section (guess why), the runner up was rooSwitch. Not knowing what that was, I thought I’d check out the website. I clicked on the link and…. got a broken web page.

That’s right, rooSwitch was one of those sites that didn’t render properly in Safari. Yup, they got an away from the makers of Safari… and Safari can’t render it. Basically all the text on the page was invisible.

I’ve since downloaded Apple’s “Security Updates”, and now Safari renders the rooSwitch page correctly. Great, so it was a security problem?!

[voice mode=”Colbert Report] So horrible Apple product launch?…. or worst Apple product launch? ;-) [/voice]

I’m going to be flying alone with my son, so to prove I’m not a kidnapper, I need to be sure to have a notarized letter from his mother saying I’m allowed to leave the country with him. The notarized part really gets me, because the whole notary system depends on two things a) the verifier keeps a copy of the document with the notary’s seal, so that if necessary they can trace it back to the notary in question and check their log book and b) that there is an easy way to reverse the impact of a fraudulent seal once it is exposed. Neither a) or b) apply here, so I end up spending $15 so that someone who wants to kidnap my child has to spend $2 more. Brilliant.

There’s all these weird restrictions on liquids (3oz bottles that fit in 1 quart bag, and the bag needs to be zip top… are you kidding me?), but solid or gas form is apparently AOK. I’m thinking I’ll freeze whatever liquids I need to bring through and hope they don’t thaw out until I’m safely passed security.

Of course, there’s enough other exceptions to drive a truck through, so no need to bother with freezing things. With all these exceptions, one has to ask why bother with the restrictions at all? They seem more oriented around how much inconvenience they’d cause the passengers (and believe me I appreciate this, as I value such conveniences and I’m quite confident that I’m not up to anything nefarious on this trip) rather than any kind of security risk profile (this part I don’t like so much). So somehow water, apple juice, toothpaste or shampoo is a major security concern, but insulin, KY jelly, and bras filled out with gels or liquids are not.

The best one is the baby formula/milk/breast milk exemption. If you have a child with you, you can take as much of this stuff as you want. They promise they won’t test or taste it, or make you or your child test or taste it. So I gotta ask… is a guy traveling alone with a 12oz carton of what is claimed to be milk really more of a security threat than a baby with a 12oz baby bottle containing the same substance, particularly if the baby never drinks from it?

It’s been five years, and it still seems like these rules are set up by the Keystone Cops. The shocking thing is that it is not at all clear to me how we can stop this insanity. Any ideas?

Okay, I have to admit the notion of some TSA employee off in a room somewhere watching our naked bodies as we walk through the airport seems pretty awful, particularly for the TSA employee. Of course, the one highlight of the TSA employee’s day has been ruined by blurring of certain parts of the shot (not quite sure how they get the system to cover the right parts given all the funny shapes we come in, but we’ll hope it’s effective). Now that the titillating issue has been dealt with, we can start catching terrorists, right?

Problem one: you get to choose whether you use it. This has to be the stupidest part of the whole thing. Before, you had to face the pat-down. Now, you can choose between the pat-down and the fancy X-ray machine. So now, someone attempting to compromise the integrity of airport security gets to choose whichever security measure they think they have the best chance of getting by. The end result is that adding these undoubtedly expensive machines provides no additional security over the traditional pat-down (if it was going to catch something the pat-down would miss, the attacker would simply elect for a pat-down), it potentially weakens security (if there is something that the pat-down would catch that the X-ray wouldn’t).

Problem two: you have to fail the initial test in order to get sent to this one. Much is made in the article of the ability for these new machines to “detect plastic and liquid explosives and other non-metallic weapons that can be missed by standard metal detectors”. The machine might be able to do it, but the security process they’ve got set up likely won’t, because you don’t get sent to this machine unless the “standard metal detectors” detect something. So, the machine really only helps reduce the number of false positives, doing nothing for all the false negatives we’re all freaking out about. There is a benefit to reducing the false positive rate (and lord knows the standard metal detectors seem to detect nothing but false positives), but frankly this seems like a horrible waste.

For the machines to be effective, the protocol ought to be something like random and/or TSA employee selection, with no choice for the target. Of course, trying to implement such a policy is going to be a nightmare. You’ll probably have people screaming in airports, lawsuits from the ACLU, etc., etc.

Which brings me to the more logical solution: just don’t do it. These machines are undoubtedly horribly expensive and do create serious privacy concerns. Worse still, you just know that this means more young boys are going to fall for those stupid X-ray glasses ads in the back of comic books. ;-) I’m sure we can spend the money on far less controversial and effective security measures, like checking more of the containers that get shipped in through our ports.

So why do this? Well, for starters, you know someone is making a killing on this. More importantly though, by giving us a new airport security measure that while ineffective is very titillating and demonstrates yet another new technology to protect air travelers, it helps spread the news (and nothing spreads faster than a titillating story that people can talk while pretending to focus on the privacy issue ;-) that it really is safe to fly again. Ultimately, that seems to be more of a concern than providing effective security measures.

I think my New Years resolution ought to be to always wear a tin foil hat when flying, as it will undoubtedly enhance my safety more than most measures that have been put in place in the last five years.

Of course, none of this should be a surprise to anyone. The efficacy of a name-based “No Fly” list has beeen questioned by security experts from the day it was first implement. There are so many ways it is a bad idea it’s hard to know where to start: terrorists aren’t exactly stupid enough to operate under a known alias, if they are you should be able to catch them fairly quickly, what are the odds that you know someone is intending a terrorist attack while on a plane without having a more precise fix on their identity than their name, names don’t map to a single person, and then there’s the fact that the list is so widely distributed that they have to keep a lot of names off the list to avoid tipping off targets that they are on their trail.

Given my own name, I’m intensely aware of the problems with name-based identification. I still remember being “Christophe cinque” in my high school French class because there were 6 Christophe’s in the class (representing about 1/4 of the class). At that same school there was another student with the same first and last name as me (and to add to the problem we had about the same size and build, similar physical traits, our dad’s worked for the same company, etc.). This was in a school with less than 500 students. I’ve had similar problems whenever dealing with bureaucracies of managing more than a few hundred people.

This problem is magnified by the fact that certain cultures tend to have limited name space. For example, in Arab culture (bets that there are a lot of Arab names on that list?) most of the population’s first names are drawn from a very small set of names of religious and cultural figures, with an even smaller subset being the most common. As a consequence Arabs are sometimes uniquely identified by citing their family tree (“ibin X ibin Y…”). Combine that with last names being common because families are often large, and you quickly discover that with perhaps 1,000 names you could probably cover a majority of the Arab population (this probably explains how the names of 14 of the 19 dead 9/11 hijackers are on the list).

Now, one could argue that maybe the security checks are more sophisticated than the public is aware of. Maybe if they get a hit on a list that just means the TSA calls up the FBI, sends an ID number or a photo, and clears a person quickly and quietly. Even better, since these days you have to provide an ID number just to buy a ticket, these hits could be prescreened. The only problem is that CBS found 12 people named “Ralph Johnson” who are detained “almost every time they fly”. Here’s a thought: if he’s cleared to fly one time, perhaps this particular Ralph Johnson should be cleared to fly subsequent times, particularly if a new terrorist “Ralph Johnson” has yet to be identified.

The truth that we all know is that a lot of the security measures that have been instituted since the 9/11 attacks, particularly those related to air travel, serve more to instill the public with confidence about their safety rather than to provide a real security benefit. Building up the public’s confidence has been necessary because politicians and the media have been self-servingly fanning the flames of the public’s fear rather than appealing to reason. The end result is unreasonable fear and unreasonable security protocols that if anything harm public safety by increasing paranoia without providing any practical security benefit.

The government isn’t the only source of this “all show and no go” approach to security. I’ve seen news reports raising the panic flag over the realitively easy access contractors have to small quantities of cesium, freaking out of “terrorism futures” markets, and playing to xenophobia by trumpeting how US ports will be run by a UAE-based conglomerate. Appealing to the public’s irrational fears is good business, regardless of whether you are a politician tyring to convince people that only you can protect them, a news outlet trying to get eyeballs, or Roger Corman. At least in the latter case the audience knows going in that it’s just a fantasy.

It’s time for everyone in the theatre to stand up and tell the people shouting fire to shut up. We simply don’t have the resources to be waste on feel good measures that accomplish little if not nothing. Security is a business that requires the same cold and calculating process that is employed by those most successful in overcoming it.

I can’t count how often I’ve seen code like this:

size_t buffer_size;
...
/* skip on down to the evil stuff */
unsigned char *iter = buffer;
while ((*iter++ = getc(file)) != EOF) {
  if ((iter - buffer) == buffer_size) {
    buffer_size += buffer_size;
    buffer == realloc(buffer, buffer_size);
  }
}

All is well and good unless buffer_size ever gets to be greater than SIZE_MAX/2, and then suddenly you are writing off in to lala land. Yeah, that’d mean realloc() would have to succeed in allocating >SIZE_MAX/2 memory, but with our modern systems still primarily running 32-bit code, despite having multiple gigs of memory, this isn’t exaclty unheard of. Code like this can be found everywhere. Heck, if you check back a few generations of GNU’s corelib functions you’ll find something almost exactly like the above.

Statically typed functional programming languages tend to handle this issue either through boxed types. Dynamically typed languages tend to this by simply checking for overflow and automagically promoting to wider and wider arithmetic types in the event that an overflow occurs. Both approaches are decent approximations of an ideal solution, but they are both a response to the problem that mainstream languages seem to have their head in the sand about.

I’ve mentioned this to some people, and have received comments like “well C is very close to the metal, so they want to expose you to how the CPU does the math”. Great! Most CPU’s have an overflow register just waiting to let you know that all hell has broken loose, so surely C takes advantage of this? ;-)

The reality is that with a simple check of a register value, we can save ourselves a ton of bugs. This is a really cheap safety feature that one could always disable in performance sensitive code that had been carefully reviewed.

What brought this to mind was that I was dusting off some old code that I’ve recovered from a crashed drive and I found an old project of mine called “checkedmath” which addressed this shortcoming in C++. C++, for all of it’s shortcomings, provides just enough support for metaprogramming that you can generally come up with way to address a lot of its shortcomings in code. In this case, I added overflow checking by taking advantage of operator overloading. I’m going to polish it off a bit before posting it, but the basics look something like this:

template <typename T>
struct CheckedNumber {
    CheckedNumber<T> operator+=(const T aNumber) {
        if (value >= 0) {
            if ((std::numeric_limits<T>::max() - value) < aNumber) {
                throw arithmetic_bounds_exception(*this, aNumber, "+");
            }
         } else if ((std::numeric_limits<T>::min() - value) > aNumber) {
            throw arithmetic_bounds_exception(*this, aNumber, "+");
         }
         value += aNumber;
         return *this;
    }
private:
    T value;
};

Now, that doesn’t take advantage of the hardware’s overflow detection, but my plan was always to get out a generic version that could pretty much work on any platform and then write some more efficient specializations in inline assembler (if I ever got around to re-bootstrapping my assembly programming knowledge) at a later date. The actual code is more generic than the above (probably more than it needs to be really), but you get the idea.

The reason I never finished this project was that after I figured out how to do it right, it occured to me that surely someone else had already done the same thing. Now it’s been a year later and I have yet to see anything like this. So, I’m going to throw it out to the blogosphere: anyone seen anything like this?

UPDATE: Apparently VB does handle overflow.

UPDATE: Looks like Microsoft has SafeInt. It doesn’t do boxed types and lacks optimizations, but it’s still a good start. I may still push my CheckedNumber implementation out at some point, but at least there is a semi-decent implementation of checked arithmetic out there.