April 2006 - Posts

Security Reporting - how critical is "Critical"?

What's the difference between these two vulnerability reports?

  1. Firefox "focus()" Memory Corruption Weakness
  2. Internet Explorer "object" Tag Memory Corruption Code Execution

Okay, so the first couple of differences are obvious - the Firefox one is "Not Critical", as it is a "Denial of Service" attack; the Internet Explorer one is "Highly Critical", as it allows "System Access" (execution of code).

Now, let's look at the details - particularly, the original advisories on which these are based...

The Firefox bug: "can be exploited to corrupt the memory and cause a crash...", "By manipulating this feature a buffer overflow will occur."

The Internet Explorer bug: "At first sight, this vulnerability may offer a remote compromise vector,
although not necessarily a reliable one.
"

Okay, so in neither one has a remote execution been demonstrated.  Each one allows the remote attacker to corrupt memory.  Why the difference in criticality?

Obviously, I'm missing something here, but I'm not sure what it is.  Anyone out there have a better clue than I do?

Posted by Alun Jones | with no comments
Filed under:

Banks and SSL forms

I just knew this message was going to get badly diluted as it progressed.

What Ullrich has 'discovered' is that banks provide the form to their users over a plain-text link - while taking the input from the form using an SSL link.

This means that your password is not exposed to the Internet in clear-text, if you enter it into your bank's form.

However, it means that you have nothing to prove that you are really connected to your bank's form, other than a vague feeling that you typed in the right address, so anything that comes back must be from your bank.

With DNS hacks, and viruses that replace or edit your host file, that's not a guarantee of anything very much, sadly - so these days, you should want your bank to identify themselves via a certificate - and that can only be done through an SSL link.

How do you know if the form on your screen has been delivered by SSL?  That's what the 'padlock' icon shows:

The only problem... you also want your password to be sent back using SSL, and currently, there's no browser that I am aware of that will tell you that this is the case, or prevent your form details from traveling back unprotected.

[It's actually a computationally "hard" problem - possibly even computationally "impossible", so let's not be too down on the browser vendors.]

Two-factor authentication - what's not to like?

Steve Riley always makes me think, sometimes so much that it hurts.  Thanks, Steve.  His latest blog posting is about two-factor authentication, and he's asking for input on what you (we) want from it.

First, a couple of examples on authentication.

  1. "I am Bill Gates." - this is not authentication.  It's identification.  The fact that it's an untrue claim doesn't prevent it from being identification.
  2. "I am Bill Gates, this is Steve Ballmer, he'll vouch for me." - this is not authentication either.
  3. "I am Bill Gates, you already know Steve Ballmer, well he'll vouch for me." - this is weak authentication.
  4. "I am Bill Gates, you already know Steve Ballmer well, he'll vouch for me." - this is strong authentication.
  5. "I am Bill Gates - last time we spoke, I told you my favourite colour was red." - this is authentication with a pre-shared secret.
  6. "I am Bill Gates - see, I still have the signed business card you gave me." - this is authentication with a token.
  7. "I am Bill Gates - watch as I ignore the $1000 bill you left on the couch." - this is authentication by ability (only a small number of people can afford to ignore free money).

There's an old saying that goes something like "You can authenticate with something you are (biometrics), something you know (passwords), something you have (SecurID etc), or something you can do (skills measurement)."  Or, to put it another way, "something you used to be, something you have forgotten, something you lost, or something you can only do when relaxed in a well-lit room."

The biggest deal we find with two-factor authentication is that the authentication device will be lost, destroyed, mangled, forgotten, given away as a prize at a sales talk, swallowed, or will simply refuse to operate in the Alaska (or Adis Ababa) office.

So, the second-factor (and if you're replacing passwords with the factor, it's not two-factor, it's still one-factor!) has to be rapidly recoverable, re-deliverable, overridable, revokable (and ideally, unrevokable when they find it in their other trouser pocket), etc.  If I lose it, can you get me another one in the five minutes before I give my presentation?  [And if you can override it, what's to prevent a hacker from doing the same?] n

Then you have to consider the message you send your staff by giving them security devices. "With these, your account is secure." This means that they will use those skanky, dirty, disgusting computers in "Fly-By-Nite Internet Cafes Incorporated (Under New Management)", or the clean ones at the airport that scream "definitely legitimate", to download salary data on your most-valued executives, to view listings of covert agents in life-threatening deployments, to investigate your proctology results, etc.

What about those of us that wear multiple hats?  The consultants, the guys with an extra job?  How many tokens are we going to carry around with us?  One password per job is already fairly complexificated, but now you want us to remember a password _and_ carry around a half-dozen "key fobs"?  Perhaps a SecurID, Smart Card, or similar token should be able to authenticate against multiple servers - servers that don't trust one another, and will not share keys.

Have I forgotten anything else you expect from a second-factor authentication method?

ActiveX behaviour change causes seizures.

The new ActiveX change will, apparently, cause seizures, and prevent ActiveX controls from running at all until clicked on. At least, that's if you believe TechWeb

Sadly, SANS chose this page, with its stunningly inaccurate and poorly worded description of the new ActiveX change, as their main link to describing what's going to happen.

The real deal of the change is far simpler.  If you want to send mouse input (including "mouseover" messages), or keyboard input, to an ActiveX control, you have to select the ActiveX control first to 'activate' it.  That's all - the controls will run; music will play, the pigs will still dance, but you just won't be able to tickle them until after you click (or tab and space/enter) on them.

So, no, ActiveX will not cause seizures.

Posted by Alun Jones | with no comments
Filed under:

Immigration idiocy

I'm struck by how many people are shown on the news spouting claptrap about immigration reform.

The biggest offence, in my opinion, is to stand there and say that illegal (or "undocumented", if you prefer) immigrants are law-abiding, tax-paying residents.

Okay, number one... they are not law-abiding, or they would have abided with the law that says they should not enter the country without documentation.

Number two... if they are tax-paying, then they have compounded their law-breaking on entering the country by filing a false tax return.  How do I know it's a false tax return?  Because, as undocumented immigrants, they have no social security number, and therefore must be filing with a fake SSN - either one that's made up, or one that already belongs to another person.

Oh, hey, that there's identity theft, too.  Imagine the mess you'd get in trying to sort out your social security if that happens to you - particularly if the social security lot give you a refund for overpayment, and then discovers later that they shouldn't have.

So, next time you hear of a "law-abiding tax-paying undocumented immigrant", think to yourself "engaging in identity theft, filing false tax returns, and continuing to evade detection and prosecution for a crime already committed".

I spent a lot of time, effort and money that I could ill-afford to legally enter this country, even answering, without giggling, the many stupid questions on the immigration form ("Are you entering the country with the intent to overthrow or subvert the government?", "Have you ever taken part in genocide?")

I don't ask you to agree with me (hey, if I sway your political opinions, does that mean I'm engaged in "subverting the government"?), but I do ask that you consider that while there are certainly some appalling abuses of human rights by employers of undocumented aliens, that does not necessarily make it right that anyone who evades the law for long enough should get a free pass into the country, nor does it mean that these individuals are "law-abiding".

Posted by Alun Jones | 4 comment(s)

The hardest working woman in IT

This is a picture of the hardest working woman in I.T.:

I know she must work hard, because not only is she in the front page of Webroot's web site, but she's also in several print adverts.  I've seen her in Global Knowledge's adverts, and a couple of the 'cheap adverts' at the back of several trade journals.

Please include some links below of places you've seen her.

Posted by Alun Jones | 4 comment(s)

Signs your crypto is wrong.

Here are a few signs that you might be doing crypto the wrong way:

  1. You're using a third-party library "because .NET keeps throwing exceptions".
    Explanation: .NET's cryptography routines throw exceptions when you are doing something wrong.  If you are getting exceptions, you need to figure out why.
  2. You are encrypting (or trying to encrypt) with the private key.
    Explanation: You encrypt with the public key, you decrypt with the private key.  You sign with the private key.  Yes, signing involves an encryption with the private key, but that's the only time you should encrypt with the private key - and then, you should be doing the hash and sign together.  .NET will throw an exception if you try and encrypt data with a private key.
  3. You are decrypting (or trying to decrypt) with the public key.
    Explanation: see sign number 2.  If your protocol requires you to decrypt with the public key, except as part of a signature verification step, then it is broken.
  4. You are designing your own protocol, rather than copying from someone else.
    Explanation: Cryptography is hard to get right.  Cryptography needs to be done using published and analysed methods, to know that you are getting it right.  Everything you are trying to do with cryptography has already been done.  Copy from others.
  5. You have started writing your final program before finishing reading the book.
    Explanation: Most books discuss the simple concepts first, and the subtler concepts are left for further in the book.  If you start coding before you have met some of the subtleties, you will paint yourself into a corner, or you will release a half-finished piece of crypto.
  6. You are writing SSL code, but you do not know what "close_notify" means.
    Explanation: close_notify is part of the SSL protocol spec.  Without it, you don't know if your session was interrupted by a forged closure.  It's covered in chapter eight of the book I read.  See sign 5.

I expect to have more signs later.

Desensitisation

Sandi Hardmeier's blog is always an interesting read.

Today, she talks about the risks of desensitisation, and the tendency of human beings to trust email from certain sources.

I tell all my users, "Don't trust email attachments.  From anyone, at any time."  No exceptions.  No "Unless you know/trust them."

Do not trust email attachments.

It's that simple.

Does that mean "do not use email attachments"?

No, it means that you should verify that any email attachment you receive is virus free, and that it was sent by the person you think sent it, and that you have a good reason to risk opening it.  A phone call to the sender will verify that the attachment was sent, and what its purpose is, so that you can gauge its risk.  A virus scanner will allow you to verify that it's virus free (as far as the most recent update of your virus scanner is concerned).

If you trusted the email attachment, you would do none of this, and simply open it.  So, and I can't repeat this often enough, never trust email attachments.

Posted by Alun Jones | with no comments
Filed under:

IDE ate my source code

A tale to chill the blood of developers everywhere: "My IDE ate my source code" [For non-developers, "IDE" means "Interactive Development Environment", and is how developers like to edit source code.]

My attention was drawn to the line "I've been using Borland IDEs on and off for the past 17 years or so, and nothing like that has ever happened before."

Quite frankly, I gave up using Borland IDEs oh, a little over ten years ago, because the IDE I was using did exactly that - ate my source code.

I'd typed in a bunch of new code, and wanted to test it, so I pressed the button to debug my code.  Of course, the code crashed, and this being 1995, and on Windows 3.1x, it took the operating system with it.

After I rebooted, it became clear that my last several hours' worth of work had not been saved.  Say whuh?

The Borland IDE of the time would happily compile code without first saving it.  [My first thought was "how can it even do that?  The compiler works from source files on the disk, surely?", but I confirmed that you could create and compile an entire application without it ever hitting the disk except as object and executable code!]

[How is this security related?  Let's say you fix a security flaw, and make a bug fix elsewhere.  You test the code - the security flaw fix works, the bug fix crashes when you test it.  So you reboot, and go make the bug fix in a different place, thinking your security fix is still in place...]

Posted by Alun Jones | with no comments

Security Exposure - it's your behaviour, not your system

Along the lines of the new theory of child-raising, where you teach that "Stranger" is a behaviour, not a person, I saw today this blog posting from the Microsoft Antimalware team.

It highlights that in a recent analysis of the results from the (Malicious Software) (Removal Tool)(*), the most frequently detected piece of malware by far ( more than 6 times ) is a Trojan that pretends to be a crack for various popular software, and makes itself available on various P2P services.

If there's a system that is vulnerable to this exploit, it's the human central nervous system.  Layer eight.  Between the chair and the keyboard.

If you're getting infected by this, I have one question - why are you killing your system?

Here's a (loose) definition of malware: untrusted code from unknown people.

Here's what you download and run when you get cracks from p2p networks: untrusted code from unknown people.

Oh, and to join in another argument that's raging right now, "untrusted code from unknown people" can also describe what you get when you install unapproved patches by parties other than the vendor / developer of the code that you're patching.

Practice safe hex.  Always get your software from a trusted dealer, and don't try to skimp on the cost of the software.

(*) As opposed to the Malicious (Software Removal Tool)

Posted by Alun Jones | with no comments
Filed under:

What is identity, anyway?

Digital ID World has a blog called "Editor's Corner" - and in a recent edition, they talk about "Network Access Control", and how it's "all about Identity".

It is, and it isn't, about Identity.  To say it's "all about identity" misrepresents NAC.

Network Access Control / Protection / Quarantine / Segregation or whatever you want to call it, is about verifying that machines meet your standards ("policies") before you allow them to connect to your network.

Your individual "standard" decides whether this Authorisation task includes an Identity requirement.  If I say "all computers on my network have to have a valid user logged on", then it's an ID requirement.  If I say "all computers must submit to a vulnerability scan and pass", then there's no identity involved.

Identity ("ID", not "ID10T"), Authentication ("AuthN"), and Authorisation (for some strange reason, this gets abbreviated to "AuthZ") are so closely interwoven that it's tempting to view them all as the same thing.  But they are not.

Identity is a claim. ["I am Alun Jones"]

Authentication is proof of a claim of identity ["I sign my name the same way as you have it on record for Alun Jones", "I know the password that has been previously associated with Alun Jones"], or of group membership ["I am English", "I have brown hair", "I am an MVP"].  Authentication does not always require identity, although it is frequently implemented that way.

[Some people combine Identification with Authentication into the term "Authentification".  I think that's a bad idea.]

Authorisation is a provision of access to resources ["I approve this request to handle the crown jewels", "Open up the vault"], and can be based on identity ["This guy says he's Alun Jones, so show him the developer pages, but not the administrator pages"], authentication ["We know this guy is Alun Jones, so let him access his bank information"], or other standards ["I don't know who you are, and I don't care who you claim to be, you're the tenth person through the gate, so you don't get to board the plane without a search"].  As you can see from my examples, authorisation doesn't always require identity or authentication, but in most cases, it does.

The differences between these concepts are subtle enough that it can be difficult to tell when you've blurred the lines.  As Steve Riley points out, it is hugely important to realise the differences, and to keep them separated.

Posted by Alun Jones | with no comments
Filed under:

I'll take three... no, make that forty...

Microsoft today announces new pricing on Virtual Server 2005 R2.

In an effort to remove the vaguaries introduced by currency exchange and commissions, the price is the same in all currencies.

The Virtual Server product line allows you to create "virtual computers" inside your system, and control when and how they run.  Here are some great potential uses for them:

  1. Testing suspicious sites without infecting your main machine. [Yes, it's much safer to use a physically separate machine, but hey... what can you do?]
  2. Debugging malware to find out what it does and how to trap it. [Again, a physical separation is better...]
  3. Creating a truly 'offline' root certificate authority (burn the Virtual Hard Drive onto a CD-ROM) that is easy to lock away.
  4. Trying patches out without sacrificing your main machine.
  5. Comparing different operating systems in their reactions to tools / patches / malware.

I'm sure there are many more uses that you can think of.  These are just some that come to my mind immediately.

Do you have any other ideas?

Posted by Alun Jones | 1 comment(s)
Filed under:

What I learned at Microsoft

This is the start of a new category - "What I learned [while employed] at Microsoft".  Nothing here will be NDA material, but it'll give you an insight into the non-Borg nature of the company.

Oh - and the non-Borg-ness?  That I learned well before going to work at Microsoft - there are so many people there, it'd be impossible for there to be a hive-mind.  This explains why stuff that "Microsoft should know" is actually not known by all at Microsoft.

The first one's easy.

The most common reason given for missing meetings, or arriving late?

"Sorry, Outlook ate my invite."

If Microsoft (or, rather, the Outlook team) wants to improve Outlook, a little inward-look would help them discover some of its more obvious pain-points.  After that, the Outlook team should look outward to the people who use functionality that Outlook is supposed to support, but which isn't core to the way Outlook is used at Microsoft.  For instance, people who use Outlook with a generic POP or IMAP server, rather than with Exchange.  There are things that Outlook can't do now, that POP clients of a decade or two ago handled without complaint.

My favourite example is that of downloading the same message twice, the second time being after a connection interruption.  Truly frustrating if you're faced with a few hundred email messages to download from a hotel room with dodgy dialup.

Posted by Alun Jones | with no comments

Septoplasty update

In my post "Scott Adams is a whiner", I mentioned that my septoplasty wasn't so bad - I spent a couple of days, as is usual when you have surgery, recovering, and I missed a couple of days of work.

Then there was the week of not being able to blow my nose, and of having to rinse twice a day with a liter of salt water - not fun, but then again, not painful either.

Finally, came the moment when the splints were to be removed.

You know that scene in Star Trek II, Wrath of Khan, when the bug crawls out of Bester's ear?

Yeah, that's what it was like.

You lean back, they snip the string on the splints (was that to prevent me from sneezing them out, or to prevent them from accidentally being swallowed?), and ask me to breathe out as, one by one, they pull out these huge slug-like pieces of what appears to be silicone gel.

Looking at the splints, as they lay on the tray in front of me, I couldn't help but think that all these years of nose-picking, I'd been an underachiever - I should have been able to get my index fingers up both nostrils at the same time, right the way up to the web.

My next thought was "my %deity% - does everyone breathe like this?"

It was amazing - even when I took a breath in through my mouth, air came in through my nose.

And when I closed my mouth, I could actually suck in huge lungfuls of air with ease without really trying. [And I have big lungs]

It's now about a month later, and I can definitely say that although my nose still feels a little tender, and I'm not allowed to ride my unicycle for a while (too much danger of banging my nose), I would recommend this surgery to anyone with a deviated septum.

Posted by Alun Jones | with no comments

Interesting fingerprint idea

I can't wait for this one to make its way to the biometric device range...

Detecting lifestyle through chemicals deposited in fingerprints.

Please do not wash your hands before authenticating.

Posted by Alun Jones | with no comments
Filed under:

New ideas from the house of crypto...

Below you'll find images of my next project in progress.

I'm building on the idea of the RAID - Redundant Array of Inexpensive Disks - where a number of cheap disks with relatively high failure rates are stacked together, connected, and controlled in such a way that they appear to be a single storage device.  These disks can be used in a number of different configurations - striped, so that a number of slow disks can achieve a faster sustained throughput by working in parallel; mirrored, so that a failure on one drive does not cause failure of the storage as a whole; or some combination.

I have figured for a while that this idea needed to be embraced and extended, and with the number of free or cheap thumb-drives that I have cluttering up my desk drawer, the idea came to me that I should create the "RAFT" - Redundant Array of Free Thumbdrives.

As you can see, the prototype, which includes a Free Hub at its centre, runs on four thumb drives of various sizes producing storage nearly equivalent to 256MB.

Let me know what successes you've had with floating your own RAFTs.

Posted by Alun Jones | with no comments