Archive for December, 2006

Authority bypasses people security

Thursday, December 7th, 2006

I was reading this post over at Apex Assurance.

On my way back to the office from a meeting today, I decided to stop at a drug store* to get a drink and a snack. It’s a brand new building, and you’ll see why that’s important in a minute. I find a spot in the crowded parking lot and head towards the door, which to my surprise, doesn’t open automatically. “Eh, whatever, I’ll just slide it open.”

The place is a little messier than I expect from a brand new establishment, but whatever. I’m not one to judge. I walk to the back, grab a soda, walk around to the front, grab a snack, and then head for a cash register. Which I can’t find. Now, this is just silly. Maybe they’ve replaced traditional registers with some revolutionary payment system. I keep poking around… nothing. Then it hits me… the place isn”t even open for business yet!

Ray’s experience reminded me of a research project I read about a while ago in the book Influence by Cialdini (this book is required reading for security and sales people alike) that went something along the lines of people being asked to shock a supposed test subject when they gave wrong answers to some sort of test, with the shocks increasing in power each time a wrong answer was given. The person giving the shocks was accompanied by someone that was pretending to oversee the experiment. The reality was that the person being shocked and the person overseeing the tests were all in on the experiment (i.e., no shocks were really being given), and the real test subject of the experiment was the person giving the shocks. Now, the person being shocked would give more and more wrong answers as the shocks grew in intensity, and they eventually cried out in agony, plead for no more, and even went so far as to say that they had heart conditions or something like that. You would expect the person giving the shocks, a person just like you or me, to stop giving the shocks as the torture grew.

So, what happened? When the person overseeing the shocks seemed like a professor, the person giving the shocks would continue giving them, even when the person being shocked screamed horribly in pain and yelled about heart disorders and the like, as long as the “professor” told them to do so. When the person overseeing seemed like a grad student, the person giving the shocks would stop at some point when the person being shocked started to cry out in pain, regardless of whether of the “grad student” pushed them to continue with the shocks. It came down to the person overseeing appearing like they had authority (i.e., a supposed professor versus a supposed grad student), whether or not that authority was real. When you think about the con artist dressed in an expensive suit running a scam, this effect is in play as well (not to mention, sales guys).

It makes me think that perhaps the workers just thought Ray looked like an owner or manager, and let him be. Afterall, he was casually wandering around, picking through stuff as if he owned the place, and, coming from a meeting, I imagine he was dressed in proper business attire. He looked the part, and he seemed to have authority. Game over. (Nice scam, Ray. ;) )

In the words of Cialdini, click, whirr.

2.6.19 (etc.) Linux kernel SHA384 HMAC needs slight tweak?

Tuesday, December 5th, 2006

I may be missing something here, but I think that as of today the 2.6.8 and 2.6.18 Debian versions of the Linux kernel as well as the stock 2.6.19 Linux kernel available from kernel.org have a very slightly broken SHA384 HMAC implementation. I do not know if this applies to any other version of the Linux kernel (nor do I care to check).

The fix is just a one line correction to the #defined SHA384_HMAC_BLOCK_SIZE found in crypto/sha512.c. This is incorrectly defined as 96, when it should just be the SHA512_HMAC_BLOCK_SIZE (i.e., 128 bytes). Afterall, SHA384 and SHA512 share everything but the initial values and truncation of the output.

I don’t know if this is new nor do I don’t keep up with whom to notify in the various communities, but, if anyone cares about the one line change, a diff between my corrected version of sha512.c and the current 2.6.18 Debian Linux kernel version (or stock 2.6.19 Linux version) of sha512.c follows.

diff linux-source-2.6.18/crypto/sha512.c /usr/src/linux/crypto/sha512.c

27c27,30
< #define SHA384_HMAC_BLOCK_SIZE 96
---
> // very minor bugfix – 12-04-2006 – Andrew Donofrio
> //#define SHA384_HMAC_BLOCK_SIZE 96
> // SHA384 block size is the same as SHA512 block size
> #define SHA384_HMAC_BLOCK_SIZE SHA512_HMAC_BLOCK_SIZE

Many people said nobody is going to use SHA384 (and, by virtue, SHA384 HMAC). It seems they were right.

Update: Ok, I was bugged by some of you to submit a proper bug report at bugzilla.kernel.org. I did so, and this bug has been assigned bug number 7646.The proposed patch is as follows.

— linux-2.6.19/crypto/sha512.c 2006-11-29 16:57:37.000000000 -0500
+++ linux-2.6.19.ad/crypto/sha512.c 2006-12-06 23:40:25.000000000 -0500
@@ -24,7 +24,7 @@

#define SHA384_DIGEST_SIZE 48
#define SHA512_DIGEST_SIZE 64
-#define SHA384_HMAC_BLOCK_SIZE 96
+#define SHA384_HMAC_BLOCK_SIZE SHA512_HMAC_BLOCK_SIZE
#define SHA512_HMAC_BLOCK_SIZE 128

struct sha512_ctx {