I have been busy making my own implementation of SHA-1. To better learn about why so many people depend on it for basically everything from SSL to tamper detection mechanism. I have a bigger project idea, but that is not important right now. What is important is that SHA-1 does everything in big endian, and I am on x86-64 which is a little endian machine.

Remember that a big endian machine has the most significant byte first, and little endian has the most significant byte last.

For example, let’s say I want a 64-bit integer to hold the number 1. This is how it’ll be stored:
Big endian:
1 = 0000 0000 0000 0000 0000 0000 0000 0001
Little endian:
1 = 0001 0000 0000 0000 0000 0000 0000 0000

SHA-1 stores the size of the message as a 64-bit integer in the last block during padding (each block is 512 bits). Since I have a little-endian machine, I wrote a function that correctly switches endian and now, the 1 appears as the as it should.

However, SHA-1 loops through each block in 32-bit integers.

*((unsigned int*)0000 0000 0000 0000) = 0
*((unsigned int*)0000 0000 0000 0001) = 16 million and change on little endian machine instead of 1 as I expect

so the second time, I have to do another endian change, this time a 32-bit endian change, so that it appears as :
0001 0000 0000 0000

so I get back 1.

This is a PITA, and a frustrating one. Mainly because I couldn’t figure it out for a few days. But feel so accomplished for figuring it out. Accomplished and embarrassed.

Here, we start initializing the AES object using CBC mode:

>>> from Crypto.Cipher import AES;
>>> aes = AES.new('some key here', AES.MODE_CBC, 'INIT_VECTOR')
Traceback (most recent call last):
File "<console>", line 1, in <module>
ValueError: IV must be 16 bytes long

oops. You’ll have to make you’re initialization vector 16 bytes long. Also, your key has to be 16, 24, or 32 bytes long as well. Let’s do something better :

>>> aes = AES.new('J2-+sfd%932mIt:{', AES.MODE_CBC, 'wir&/>H54mgd9a";')

ah! much better. Even if it was me smashing my hand against the keyboard. Now let’s encrypt/decrypt something important.

>>> aes.encrypt('the answer to life the universe and everything is 42')
Traceback (most recent call last):
File "<console>", line 1, in <module>
ValueError: Input strings must be a multiple of 16 in length

You’ll have to do the dirty work remember:

>>>> ciphertext = aes.encrypt('the answer to life the universe and everything is 42195479204957')
>>> ciphertext
'f0\xa9\xf9f&X)\x0e\x08=\x06\x97\xcbF\xddK\x1a\xa6i\x1d\x02"}\xd9\\\xaa\xb6\xd9J\xe3Q\x07\xaev\x012\xbf\rPN\xd2\xf9\xf7$\x93\xe0/\xcb\xae9\x91K\xd01\xab\xb7\xdb\reR\xff\xef\x1c'

Much better. Now lets decrypt it:

>>> aes.decrypt(ciphertext)
'\xc8\xaf.\x97\x05\x80\n\xe9\xe6\xc4Ju\x04\xbe\xa1Nfe the universe and everything is 42195479204957'

Woah! That isn’t the whole message! So what’s going on?

Remember that initialization vector you set in the beginning? That sets the stage for the first block. But each block becomes the initialization vector for the second block, and so on. So when you decrypt, it is using the initialization vector from the block before. That’s why the first 16 bytes are screwed up. This is a feature of CBC, but not ECB:

>>> aes = AES.new('J2-+sfd%932mIt:{', AES.MODE_ECB, 'wir&/>H54mgd9a";')
>>> ciphertext = aes.encrypt('the answer to life the universe and everything is 42195479204957')
>>> aes.decrypt(ciphertext)'the answer to life the universe and everything is 42195479204957'

And yes, this is a feature. Read the block cipher modes wikipedia article for a better explination. So what’s the answer? Simply, to call aes.new() again before calling decrypt!

The reason maps doesn’t support Minefield is because of *drumrolls* … browser sniffing. Developers… no wait… GOOGLE web developers, I thought we moved on?

The actual bit of code is here unminimized and tidied up ;

function isBrowserGeolocationSupported(){
    if (window.navigator &&
        navigator.userAgent.search("Firefox") != -1 &&
        navigator.geolocation)
        return true;
    if (window.navigator &&
        navigator.userAgent.search("Chrome") != -1)
        return Number(String(/Chrome\/[0-9]+/.exec(navigator.userAgent)).substr(7))>=2;
    var gearsFactory=null;

The hell? Ok, so I understand they do a bit of browser sniffing because it looks like Chrome had a old/broken implementation of geolocation. But I wish there was a more graceful way of doing this (maybe something like navigator.geolocation.version < 1). One that didn't break every application that may implement geolocation that isn't named Firefox. Because, those exist too.

But as anyone can tell you, it’s not an easy task (going towards damn near impossible). Firstly, you can’t really use a lexical parser. Well, you can, but it won’t be dependable. Let’s take an example out of the Reviewer’s guide :

document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));

Which is sneaky way of creating a script element, though I question the competence of someone who will use this as their main line of attack (it’s practically spelled out for you). But taking this as a use case, and ignoring the fact that they can use document[cheese] instead, I wondering if parsing the javascript would make figuring this stuff out any better.

Happily, I have spidermonkey and a js shell to do any parsing I wish. But I found out some cool things that you can do in the shell, such as looking at the bytecode for an entire function using the dis() command.

This was interesting. Certainly, there are some optimizations you can do for :
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
I would be shocked if it didn’t end up spelling out :
document["createElement"]("script");

I had a few hurdles to overcome. Firstly, document is not defined in the javascript shell. Thinking it was defined in the xpcshell (owww. I was misled by some apparently unused tests and my general ignorance that xpcshell tests went into unit/ and not js/ directory) I went through the added trouble of coping dis() and related functions from js.cpp to xpcshell.cpp. Once I realized that document wasn’t defined, I made a document mock object just to see what the blasted bytecode would look like.

I was a little disappointed. This source:

var document = {
createElement : function(s) {
print("damn");
}
};

function foo() {
document["crea" + "teElement"]("s" + "c" + "r" + ["i", "p", "t"].join(""));
}

dis(foo);

Ended up being this bytecode :

00000:  name "document"
00003:  string "createElement"
00006:  callelem
00007:  string "s"
00010:  string "c"
00013:  add
00014:  string "r"
00017:  add
00018:  newinit 3
00020:  zero
00021:  string "i"
00024:  initelem
00025:  one
00026:  string "p"
00029:  initelem
00030:  int8 2
00032:  string "t"
00035:  initelem
00036:  endinit
00037:  callprop "join"
00040:  string ""
00043:  call 1
00046:  add
00047:  call 1
00050:  pop
00051:  stop

Source notes:
  0:     0 [   0] newline
  1:     6 [   6] pcbase   offset 6
  3:    37 [  31] xdelta
  4:    37 [   0] pcbase   offset 19
  6:    43 [   6] pcbase   offset 25
  8:    47 [   4] pcbase   offset 47

So, almost. The document["createElement"] part was correct, but the .join() wasn’t optimized. Although I wasn’t overly estatic, I knew that this was just one (somewhat lame) use case in the countless of possible others.

This is making me rethink whether lexical tools are the way to go. While they don’t give you any definitive proof that there is a possible security hole, they can still be useful. For example, if you want to use XMLHttpRequest, then you have to call it at least once in your program (even if you say var Widget = XMLHttpRequest). And at least that can bring up warning flags, or at least give editors a place to look.

I don’t think any tool can completely replace a human being. But hopefully, tools will help make the review process easier because you can start looking at high-risk areas first rather than starting from a arbitrary point and not coming across something until 10 minutes later.

This is rather unfortunate for me. How would I get around this problem? The first thing I did was check for an updated python. Which there was a minor version upgrade. I found the changelog (why do they hide these things?) and noticed a few bugs resolved with the zipfile module. So I installed. Unfortunately, this didn’t solve my problem.

I managed to find a bug number in the python bug tracking software about people having similar problems. There was a patch, but hasn’t landed. I downloaded the latest stable version, but the patch wouldn’t go through. So I had to cvs checkout trunk and apply it. Once installed, I tried it and it worked! Success.

However, it broke other library I was using (PyXML). Unfortunate for me, the recent trunk build didn’t seem to fair any better.

At this point, I wasn’t in the mood for debugging. I had a few options at my disposal :

1. Ignore this particular file
2. Suck it up and debug it.
3. Find a whacky work-around

Option 1 isn’t an option. Option 2 I tried for a fair while, but nothing worked. So Option 3 was my only option!

I tried using a lower level library to see if I can fix the problem (zlib library), but that didn’t work well at all.

I finally thought I had no choice but to initiate a thread to try and unzip the xpi, and if it took longer than 10 seconds, to kill the thread somehow. While seriously looking into this, and fighting the temptation to take tequelia shots at work. I came across signals (which I thought I could use to send to the thread. I’m so naive). It turns out, you can throw a signal after a specific number of seconds and it throws the SIGALRM. This was exactly what I needed without the extra complexity. The example provided was almost exactly what I did too! Here is my solution to the problem :

		signal.signal(signal.SIGALRM, signal_handler)
		signal.alarm(10)
		try:
			zippy = zipfile.ZipFile(io, 'r')
			signal.alarm(0)
		except:
			print "\tZipFile Timeout"
			continue

Maybe python isn’t just for programming sissies after all.