Larry Osterman's WebLog : Security

Why are they called “giblets” anyway?

LarryOsterman — Mon, 26 Oct 2009 16:05:33 GMT

Five years ago, I attended one of the initial security training courses as a part of the XP SP2 effort. I wrote this up in one of my very first posts entitled “Remember the giblets” and followed it up last year with “The Trouble with Giblets”. I use the term “giblets” a lot but I’d never bothered to go out and figure out where the term came from.

Well, we were talking about giblets in an email discussion today and one of my co-workers went and asked Michael Howard where the term came from. Michael forwarded the question to Steve Lipner who was the person who originally coined the term and he came back with the origin of the term.

It turns out that “giblets” is a term that was used at Digital Equipment Corporation back in the 1980s. DEC used to sell big iron machines (actually I used DEC machines exclusively until I started at Microsoft). The thing about big machines is that you usually need more than just the machine to build a complete solution – things like Ethernet repeaters and adapters and other fiddly bits. And of course DEC was more than willing to sell you all these fiddly bits. It seems that some of the DEC marketing people liked to refer to these bits and pieces as “giblets”.

Over time Steve started using the term for the pieces of software that were incidental to the product but which weren’t delivered by the main development team – things like the C runtime library, libJPG, ATL, etc.

Later on, someone else (Steve wasn’t sure who, it might have been Eric Bidstrup) pointed out that the giblets that came from a turkey didn’t necessarily come from the actual turkey that you’re eating which makes the analogy even more apt.

Thanks to Craig Gehre for the picture.

Good News! strlen isn’t a banned API after all.

LarryOsterman — Tue, 23 Jun 2009 20:01:46 GMT

We were doing some code reviews on the new Win7 SDK samples the other day and one of the code reviewers noticed that the code used wcslen to compute the length of a string.

He pointed out that the SDL Banned API page calls out strlen/wcslen as being banned APIs:

For critical functions, such as those accepting anonymous Internet connections, strlen must also be replaced:

Table 19. Banned string length functions and replacements

Banned APIs StrSafe Replacement Safe CRT Replacement

strlen, wcslen, _mbslen, _mbstrlen, StrLen, lstrlen String*Length strnlen_s

I was quite surprised to see this, since I’m not aware of any issues where the use of strlen/wcslen could cause security bugs.

I asked Michael Howard about this and his response was that Table 19 has a typo – the word “server” is missing in the text, it should be “For critical server functions, such as those accepting anonymous Internet connections, strlen must also be replaced”.

Adding that one word makes all the difference. And it makes sense – if you’re a server and accepting anonymous data over the internet, an attacker could cause you to crash by issuing a non null terminated string that was long enough – banning the API forces the developer to think about the length of the string.

Somewhat OT, but I also think that the table is poorly formatted – the “For critical…” text should be AFTER the table title – the way the text is written, it appears to be a part of the previous section instead of being attached as explanatory text on Table 19 (but that’s just the editor in me).

Apparently in SDL v5.0 (which hasn’t yet shipped) the *len functions are removed from the banned API list entirely.

Chrome is fixing the file download bug…

LarryOsterman — Tue, 21 Oct 2008 00:17:00 GMT

I just noticed that Ryan Naraine has written that Google’s fixed the file download bug in Chrome. This is awesome, but there’s one aspect of the fix that concerns me.

According to the changelog:

This CL adds prompting for dangerous types of files (executable) when they are automatically downloaded.

When I read this, my first thought was: “I wonder how they determine if a file is ‘dangerous’?”

One of the things that we’ve learned over time is that there are relatively few files that aren’t “dangerous”. Sure there are the obvious files (.exe, .dll, .com, .bat, etc) but there are lots of other file types that can contain executable content. For instance most word processors and spreadsheets support some form of scripting language, that means that most documents downloaded can contain executable content.

Even if you ignore the files that contain things that are clearly identifiable as “code”, you’ve still got problems. After all, just about every single file format out there has had readers who have had bugs that would have allowed remote code execution.

It’s unfortunate, but given the history of the past couple of years, I can’t see how ANY content that was downloaded from the internet could be considered “safe”.

IMHO Google’s change is a good start, but I’m worried that that it doesn’t go far enough.

What makes a bug a security bug?

LarryOsterman — Mon, 18 Aug 2008 20:29:56 GMT

In my last post, I mentioned that security bugs were different from other bugs. Daniel Prochnow asked:

What is the difference between bug and vulnerability?

In my point of view, in a production enviroment, every bug that may lead to a loss event (CID, image, $) must be considered a security incident.

What do you think?

I answered in the comments, but I think the answer deserves a bit more commentary, especially when Evan asked:

“I’m curious to hear an elaboration of this. System A takes information from System B. The information read from System A causes a[sic] System B to act in a certain way (which may or may not lead to leakage of data) that is unintended. Is this a security issue or just a bug?”

Microsoft Technet has a definition for a security vulnerability:

“A security vulnerability is a flaw in a product that makes it infeasible – even using the product properly – to prevent an attacker from usurping privileges on the user’s system, regulating it’s operation, compromising data on it or assuming ungranted trust.”

IMHO, that’s a bit too lawyerly, although the article does an excellent job of breaking down the definition and making it understandable.

Crispin Cowan gave me an alternate definition, which I like much better:

Security is the preservation of:

· Confidentiality: your secret stuff stays secret

· Integrity: your data stays intact

· Availability: your systems and data remain available

A vulnerability is a bug such that an attacker can compromise one or more of the above properties

In Evan’s example, I think there is a security bug, but maybe not. For instance, it’s possible that System A validates (somehow) that System B hasn’t been compromised. In that case, it might be ok to trust the data read from System B. That’s part of the reason for the wishy-washy language of the official vulnerability definition.

To me, the key concept in determining if a bug is a security bug or not is that of an unauthorized actor. If an authorized user performs operations on a file to which the user has access and the filesystem corrupts their data, it’s a bug (a bad bug that MUST be fixed, but a bug nonetheless). If an unauthorized user can cause the filesystem to corrupt the data of another user, that’s a security bug.

When a user downloads a file from the Internet, they’re undoubtedly authorized to do that. They’re also authorized to save the file to the local system. However the program that reads the file downloaded from the Internet cannot trust the contents of the file (unless it has some way of ensuring that the file contents haven’t been tampered with[1]). So if there’s a file parsing bug in the program that parses the file, and there’s no check to ensure the integrity of the file, it’s a security bug.

Michael Howard likes using this example:

char foo[3];
foo[3] = 0;

Is it a bug? Yup. Is it a security bug? Nope, because the attacker can’t control anything. Contrast that with:

struct
{
int value;
} buf;
char foo[3];

_read(fd, &buf, sizeof(buf));
foo[buf->value] = 0;

That’s a 100% gen-u-wine security bug.

Hopefully that helps clear this up.

[1] If the file is cryptographically signed with a signature from a known CA and the certificate hasn’t been revoked, the chances of the file’s contents being corrupted are very small, and it might be ok to trust the contents of the file without further validation. That’s why it’s so important to ensure that your application updater signs its updates.

Linus Torvalds is “Fed up with the ‘security circus’”

LarryOsterman — Fri, 15 Aug 2008 23:28:00 GMT

There’s been a lot of discussion on the intertubes about some comments that Linus Torvalds, the creator of Linux has made about security vulnerabilities and disclosure.

Not surprisingly, there’s been a fair amount of discussion amongst the various MSFT security folks about his comments and about the comments about his comments (are those meta-comments?).

The whole thing started with a posting from Linus where he says:

Btw, and you may not like this, since you are so focused on security, one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.

He also made some (IMHO) unprofessional comments about the OpenBSD community, but I don’t think that’s relevant to my point.

Linus has followed up his initial post with an interview with Network World where he commented:

“You need to fix things early, and that requires a certain level of disclosure for the developers," Torvalds states, adding, "You also don't need to make a big production out of it."”

and

"What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.

As a part of our internal discussion, Crispin Cowan pointed out that Linus doesn’t issue security updates for Linux, instead the downstream distributions that contain the Linux kernel issue security fixes.

That comment was the catalyst – after he made the comment, I realized that I think I understand the meaning behind Linus’ comments.

IMHO, Linus is thinking about security bugs as an engineer. And as an engineer, he’s completely right (cue the /. trolls: “MSFT engineer thinks that Linux inventor is right about something!”).

As a software engineer, I fully understand where Linus is coming from: From a strict engineering standpoint, security bugs are no different from any other bugs, and treating them as somehow “special” denigrates other bugs. It’s only when you consider the consequences of security bugs that they become more interesting.

A non security bug can result in an unbootable system or the loss of data on the affected machine. And they can be very, very bad. But security bugs are special because they’re bugs that allow a 3rd party to mess with your system in ways that you didn’t intend.

Simply put, your customers data is at risk from security bugs in a way that normal defects aren’t. There are lots of bad people out there who would just love to exploit any security defect in your product. Security updates are more than just “PR”, they provide critical information that customers use to help determine the risk associated with taking a fix.

Every time your customer needs to update the software on their computer, they take the risk that the update will break something (that’s a large part of the reason that that MSFT takes it’s time when producing security fixes – we test the heck out of stuff to reduce the risk to our customers). But because the bad guys can use security vulnerabilities to compromise their customers data, your customers want to roll out security fixes faster than they roll out other fixes.

That’s why it’s so important to identify security fixes – your customers use this information for risk management. It’s also why Microsoft’s security bulletins carry mitigating factors that would help identify if customers are at risk. For example MS08-045 which contains a fix for CVE-2008-2257 has a mitigating factor that mentions that in Windows Server 2003 and Windows Server 2008 the enhanced security configuration mode mitigates this vulnerability. A customer can use that information to know if they will be affected by MS08-045.

But Linus’ customers aren’t the users of Linux. They are the people who package up Linux distribution. As Crispin commented, the distributions are the ones that issue the security bulletins and they’re the ones that work with their customers to ensure that the users of the distribution are kept safe.

By not clearly identifying which fixes are security related fixes, IMHO Linus does his customers a disservice – it makes the job of the distribution owner harder because they can’t report security defects to their customers. And that’s why reporting security bug fixes is so important.

Edit: cleared out some crlfs

Edit2: s/Linus/Linux/ :)

More proof that crypto should be left to the experts

LarryOsterman — Tue, 13 May 2008 19:46:13 GMT

Apparently two years ago, someone ran a static analysis tool named "Valgrind" against the source code to OpenSSL in the Debian Linux distribution. The Valgrind tool reported an issue with the OpenSSL package distributed by Debian, so the Debian team decided that they needed to fix this "security bug".

Unfortunately, the solution they chose to implement apparently removed all entropy from the OpenSSL random number generator. As the OpenSSL team comments "Had Debian [contributed the patches to the package maintainers], we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."

And it IS a terrible idea. It means that for the past two years, all crypto done on Debian Linux distributions (and Debian derivatives like Ubuntu) has been done with a weak random number generator. While this might seem to be geeky and esoteric, it's not. It means that every cryptographic key that has been generated on a Debian or Ubuntu distribution needs to be recycled (after you pick up the fix). If you don't, any data that was encrypted with the weak RNG can be easily decrypted.

Bruce Schneier has long said that cryptography is too important to be left to amateurs (I'm not sure of the exact quote, so I'm using a paraphrase). That applies to all aspects of cryptography (including random number generators) - even tiny changes to algorithms can have profound effects on the security of the algorithm. He's right - it's just too easy to get this stuff wrong.

The good news is that there IS a fix for the problem, users of Debian or Ubuntu should read the advisory and take whatever actions are necessary to protect their data.

Resilience is NOT necessarily a good thing

LarryOsterman — Thu, 01 May 2008 19:14:00 GMT

I just ran into this post by Eric Brechner who is the director of Microsoft's Engineering Excellence center.

What really caught my eye was his opening paragraph:

I heard a remark the other day that seemed stupid on the surface, but when I really thought about it I realized it was completely idiotic and irresponsible. The remark was that it's better to crash and let Watson report the error than it is to catch the exception and try to correct it.

Wow. I'm not going to mince words: What a profoundly stupid assertion to make. Of course it's better to crash and let the OS handle the exception than to try to continue after an exception.

I have a HUGE issue with the concept that an application should catch exceptions[1] and attempt to correct them. In my experience handling exceptions and attempting to continue is a recipe for disaster. At best, it takes an easily debuggable problem into one that takes hours of debugging to resolve. At it's worst, exception handling can either introduce security holes or render security mitigations irrelevant.

I have absolutely no problems with fail fast (which is what Eric suggests with his "Restart" option). I think that restarting a process after the process crashes is a great idea (as long as you have a way to prevent crashes from spiraling out of control). In Windows Vista, Microsoft built this functionality directly into the OS with the Restart Manager, if your application calls the RegisterApplicationRestart API, the OS will offer to restart your application if it crashes or is non responsive. This concept also shows up in the service restart options in the ChangeServiceConfig2 API (if a service crashes, the OS will restart it if you've configured the OS to restart it).

I also agree with Eric's comment that asserts that cause crashes have no business living in production code, and I have no problems with asserts logging a failure and continuing (assuming that there's someone who is going to actually look at the log and can understand the contents of the log, otherwise the logs just consume disk space).

But I simply can't wrap my head around the idea that it's ok to catch exceptions and continue to run. Back in the days of Windows 3.1 it might have been a good idea, but after the security fiascos of the early 2000s, any thoughts that you could continue to run after an exception has been thrown should have been removed forever.

The bottom line is that when an exception is thrown, your program is in an unknown state. Attempting to continue in that unknown state is pointless and potentially extremely dangerous - you literally have no idea what's going on in your program. Your best bet is to let the OS exception handler dump core and hopefully your customers will submit those crash dumps to you so you can post-mortem debug the problem. Any other attempt at continuing is a recipe for disaster.

-------

[1] To be clear: I'm not necessarily talking about C++ exceptions here, just structured exceptions. For some C++ and C# exceptions, it's ok to catch the exception and continue, assuming that you understand the root cause of the exception. But if you don't know the exact cause of the exception you should never proceed. For instance, if your binary tree class throws a "Tree Corrupt" exception, you really shouldn't continue to run, but if opening a file throws a "file not found" exception, it's likely to be ok. For structured exceptions, I know of NO circumstance under which it is appropriate to continue running.

Edit: Cleaned up wording in the footnote.

This is the way the world (wide web) ends...

LarryOsterman — Wed, 16 Apr 2008 23:03:00 GMT

Robert Hensing linked to a post by Thomas Ptacek over on the Matasano Chargen blog. Thomas (who is both a good hacker AND a good writer) has a writeup of a “game-over” vulnerability that was just published by Mark Dowd over at IBM's ISS X-Force that affects Flash. For those that don’t speak hacker-speak, in this case, a “game-over” vulnerability is one that can be easily weaponized (his techniques appear to be reliable and can be combined to run an arbitrary payload). As an added bonus, because it’s a vulnerability in Flash, it allows the attacker to write a cross-browser, cross-platform exploit – this puppy works just fine in both IE and Firefox (and potentially in Safari and Opera).

This vulnerability doesn’t affect Windows directly, but it DOES show how a determined attacker can take what was previously thought to be an unexploitable failure (a null pointer dereference) and turn it into something that can be used to 0wn the machine.

Every one of the “except not quite” issues that Thomas writes about in the article represented a stumbling block that the attacker (who had no access to the source to Flash) had to overcome – there are about 4 of them, but the attacker managed to overcome all of them.

This is seriously scary stuff. People who have flash installed should run, not walk over to Adobe to pick up the update. Please note that the security update comes with the following warning:

"Due to the possibility that these security enhancements and changes may impact existing Flash content, customers are advised to review this March 2008 Adobe Developer Center article to determine if the changes will affect their content, and to begin implementing necessary changes immediately to help ensure a seamless transition."

Edit2: It appears that the Adobe update center I linked to hasn't yet been updated with the fix, I followed their update proceedure, and my Flash plugin still had the vulnerable version number.

Edit: Added a link to the relevant Adobe security advisory, thanks JD.

The Trouble with Giblets

LarryOsterman — Fri, 07 Mar 2008 19:28:13 GMT

I don't write about the SDL very much, because I figure that the SDL team does a good enough job of it on their blog, but I was reading the news a while ago and realized that one of the aspects of the SDL would have helped if our competitors were to adopt it.

A long time ago, I wrote a short post about "giblets", and they're showing up a lot in the news lately. "Giblets" are a term coined by Steve Lipner , and they've entered the lexicon of "micro-speak". Essentially a giblet is a chunk of code that you've included from a 3rd party. Michael Howard wrote about them on the SDL blog a while ago (early January), and now news comes out that Google's Android SDK contains giblets that contain known exploitable vulnerabilities.

I find this vaguely humorous, and a bit troubling. As I commented in my earlier post (almost 4 years ago), adding a giblet to your product carries with it the responsibility to monitor the security mailing lists to make sure that you're running the most recent (and presumably secure) version of the giblet.

What I found truly surprising was that Android development team had shipped code (even in beta) with those vulnerabilities. Their development team should have known about the problem with giblets and never accepted the vulnerable versions in the first place. That in turn leads me to wonder about the process management associated with the development of Android.

I fully understand that you need to lock down the components that are contained in your product during the development process, that's why fixes take time to propagate into distributions. As I've seen it from watching FOSS bugs, the typical lifecycle of a security bug in FOSS code is: A bug is typically found in the component, and fixed quickly. Then over the next several months, the fix is propagated into the various distributions that contain the fix. So a fix for the bug is made very quickly (but is completely untested), the teams that package up the distribution consumes the fix and proceeds to test the fix in the distribution. As a result, distributions naturally lag behind fixes (btw, the MSFT security vulnerabilities follow roughly the same sequence - the fix is usually known within days of the bug being reported, but it takes time to test the fix to ensure that the fix doesn't break things (especially since Microsoft patches vulnerabilities in multiple platforms, the fix for all of them needs to be released simultaneously)).

But even so, it's surprising that a team would release a beta that contained a version of one of it's giblets that was almost 4 years old (according to the original report, it contained libPNG version 1.2.7, from September 12, 2004)! This is especially true given the fact that the iPhone had a similar vulnerability found last year (ironically, the finder of this vulnerability was Travis Ormandy of Google). I'm also not picking on Google because of spite - other vendors like Apple and Microsoft were each bitten by exactly this vulnerability - 3 years ago. In Apple's case, they did EXACTLY the same thing that the Android team did: They released a phone that contained a 3 year old vulnerability that had previously been fixed in their mainstream operating system.

So how would the SDL have helped the Android team? The SDL requires that you track giblets in your code - it forces you to have a plan to deal with the inevitable vulnerabilities in the giblets. In this case, SDL would have forced the development teams to have a process in place to monitor the vulnerabilities (and of course to track the history of the component), so they hopefully would never have shipped vulnerable components. It also means that when a vulnerability is found after shipping, they would have a plan in place to roll out a fix ASAP. This latter is critically important because history has shown us that when one component is known to have a vulnerability, the vultures immediately swoop in to find similar vulnerabilities in related code bases (on the theory that if you make a mistake once, you're likely to make it a second or third time). In fact, that's another requirement of the SDL: When a vulnerability is found in a component, the SDL requires that you also look for similar vulnerabilities in related code bases.

Yet another example where adopting the SDL would have helped to mitigate a vulnerability[1].

[1] Btw, I'm not saying that the SDL is the only way to solve this problem. There absolutely are other methodologies that would allow these problems to be mitigated. But when you're developing software that's going to be deployed connected to a network (any network), you MUST have a solution in place to manage your risk (and giblets are just one form of risk). The SDL is Microsoft's way, and so far it's clearly shown its value.

Wow - We hired Crispin Cowan!!!

LarryOsterman — Fri, 18 Jan 2008 21:31:27 GMT

Michael Howard just announced that we've hired Crispin Cowan!

This is incredibly awesome, I have a huge amount of respect for Crispin, he's one of the most respected researchers out there.

Among other things, Crispin's the author and designer of AppArmor, which adds sandboxing capabilities to Linux. Apparently he's going to be working on the core Windows Security team, which is absolutely cool.

I'm totally stoked to hear this - I literally let out a whoot when I read Michael's blog post.

Welcome aboard Crispin :).

How to lose customers without really trying...

LarryOsterman — Fri, 16 Nov 2007 02:21:00 GMT

Not surprisingly, Valorie and I both do some of our holiday season shopping at ThinkGeek. But no longer. Valorie recently placed a substantial order with them, but Instead of processing her order, they sent the following email:

From: ThinkGeek Customer Service [mailto:custserv@thinkgeek.com]
Sent: Thursday, November 15, 2007 4:28 AM
To: <Valorie's Email Address>
Subject: URGENT - Information Needed to Complete Your ThinkGeek Order

Hi Valorie,
Thank you for your recent order with ThinkGeek, <order number>. We would like to process your order as soon as possible, but we need some additional information in order to complete your order.
To complete your order, we must do a manual billing address verification check.
If you paid for your order via Paypal, please send us a phone bill or other utility bill showing the same billing address that was entered on your order.
If you paid for your order via credit card, please send us one of the following:
- A phone bill or other utility bill showing the same billing address that was entered on your order
- A credit card statement with your billing address and last four digits of your credit card displayed
- A copy of your credit card with last four digits displayed AND a copy of a government-issued photo ID, such as a driver's license or passport.
To send these via e-mail (a scan or legible digital photo) please reply to custserv@thinkgeek.com or via fax (703-839-8611) at your earliest convenience. If you send your documentation as digital images via email, please make sure they total less than 500kb in size or we may not receive your email. We ask that you send this verification within the next two weeks, or your order may be canceled. Also, we are unable to accept billing address verification from customers over the phone. We must receive the requested documentation before your order can be processed and shipped out.
For the security-minded among you, we are able to accept PGP-encrypted emails. It is not mandatory to encrypt your response, so if you have no idea what we're talking about, don't sweat it. Further information, including our public key and fingerprint, can be found at the following
link:
http://www.thinkgeek.com/help/encryption.shtml
At ThinkGeek we take your security and privacy very seriously. We hope you understand that when we have to take extra security measures such as this, we do it to protect you as well as ThinkGeek.
We apologize for any inconvenience this may cause, and we appreciate your understanding. If you have any questions, please feel free to email or call us at the number below.
Thanks-
ThinkGeek Customer Service
1-888-433-5788 (phone)
1-703-839-8611 (fax)

Wow. We've ordered from them in the past (and placed other large orders with them), but we've never seen anything as outrageous as this. They're asking for exactly the kind information that would be necessary to perpetuate an identity theft of Valorie's identity, and they're holding our order hostage if we don't comply.

What was worse is that their order form didn't even ask for the CVE code on the back of the credit card (the one that's not imprinted). So not only didn't they follow the "standard" practices that most e-commerce sites follow when dealing with credit cards, but they felt it was necessary for us to provide exactly the kind of information that an identity thief would ask for.

Valorie contacted them to let them know how she felt about it, and their response was:

Thank you for your recent ThinkGeek order. Sometimes, when an order is placed with a discrepancy between the billing and the shipping addresses, or with a billing address outside the US, or the order is above a certain value, our ordering system will flag the transaction. In these circumstances, we request physical documentation of the billing address on the order in question, to make sure that the order has been placed by the account holder. At ThinkGeek we take your security and privacy very seriously. We hope you understand that when we have to take extra security measures such as this, we do it to protect you as well as ThinkGeek.
Unfortunately, without this documentation, we are unable to complete the processing of your order. If we do not receive the requested documentation within two weeks of your initial order date, your order will automatically be cancelled. If you can't provide documentation of the billing address on your order, you will need to cancel your current order and reorder using the proper billing address for your credit card. Once we receive and process your documentation, you should not need to provide it on subsequent orders. Please let us know if you have any further questions.

The good news is that we have absolutely no problems with them canceling the order, and we're never going to do business with them again. There are plenty of other retailers out there that sell the same stuff that ThinkGeek does who are willing to accept our business without being offensive about it.

Edit to add: Think Geek responded to our issues, their latest response can be found here.

When you're analyzing the strength of a password, make sure you know what's done with it.

LarryOsterman — Tue, 13 Nov 2007 04:47:35 GMT

Every once in a while, I hear someone making comments about the strength of things like long passwords.

For example, if you have a 255 character password that just uses the 26 roman upper and lower case letters, plus the numeric digits. That means that your password has 62^255 possible values, if you can try a million million passwords per second, the time required would exceed the heat death of the universe.

Wow, that's cool - it means that you can never break my password if I use a long enough password.

Except...

The odds are very good that something in the system's going to take your password and apply a one-way hash to that password - after all, it wouldn't do to keep that password lying around in clear text where an attacker could see it. But the instant you take a hash of a secret, the strength of the secret degrades to the strength of the hash.

It's another example of the pigeonhole principle in practice - if you put N+M items into N slots, you're going to have some slots with more than one entry. The pigeonhole principle applies in this case as well.

In other words, if the password database that holds your password uses a hash algorithm like SHA-1, your 62^255 possible character password just got reduced in strength to a 256^20 possible value hash[1]. That means that any analysis that you've done on your password doesn't matter, because all an attacker needs to do is to find a different password that hashes to the same value as your password and they've broken your password. Since your password strength exceeds the strength of the hash code, you know that there MUST be a collision with a weaker password.

The bottom line is that when you're calculating the strength of a password, it's important that you understand what your password looks like to an attacker. If your password is saved as an SHA-1 or MD5 hash, that's the true maximum strength of your password.

[1]To be fair, 256^20 is something like 1.4E48, so even if you could still try a million million passwords per second, you're still looking at something like a million million years to brute force that database, but 256^20 is still far less than 62^255.

Chris Pirillo's annoyed by the Windows Firewall prompt

LarryOsterman — Fri, 02 Nov 2007 19:56:03 GMT

Yesterday, Chris Pirillo made a comment in one of his posts:

And if you think you’re already completely protected in Windows with its default tools, think again. This morning, after months of regular Firefox use, I get this security warning from the Windows Vista Firewall. Again, this was far from the first time I had used Firefox on this installation of Windows. Not only is the dialog ambiguous, it’s here too late.

I replied in a comment on his blog:

The reason that the Windows firewall hasn’t warned you about FF’s accessing the net is that up until this morning, all of it’s attempts have been outbound. But for some reason, this morning, it decided that it wanted to receive data from the internet.
The firewall is doing exactly what it’s supposed to do - it’s stopping FF from listening for an inbound connection (which a web browser probably shouldn’t do) and it’s asking you if it’s ok.
Why has your copy of firefox suddenly decided to start receiving data over the net when you didn’t ask it to?

Chris responded in email:

Because I started to play XM Radio? *shrug*

My response to him (which I realized could be a post in itself - for some reason, whenever I respond to Chris in email, I end up writing many hundred word essays):

Could be - so in this case, the firewall is telling you (correctly) exactly what happened.

That's what firewalls do.

Firefox HAS the ability to open the ports it needs when it installs (as does whatever plugin you're using to play XM radio (I documented the APIs for doing that on my blog about 3 years ago, the current versions of the APIs are easier to use than the ones I used)), but for whatever reason it CHOSE not to do so and instead decided that the correct user experience was to prompt the user when downloading.

This was a choice made by the developers of Firefox and/or the developer of XM radio plugin - either by design, ignorance, schedule pressure or just plain laziness, I honestly don't know (btw, if you're using the WMP FF plugin to play from XM, my comment still stands - I don't know if this was a conscious decision or not).

Blaming the firewall (or Vista) for this is pointless (with a caveat below).

The point of the firewall is to alert you that an application is using the internet in a way that's unexpected and ask you if it makes sense. You, the user, know that you've started playing audio from XM, so you, the user expect that it's reasonable that Firefox start receiving traffic from the internet. But the firewall can't know what you did (and if it was able to figure it out, the system would be so hideously slow that you'd be ranting on and on about how performance sucks).

Every time someone opens an inbound port in the firewall, they add another opportunity for malware to attack their system. The firewall is just letting the user know about it. And maybe, just maybe, the behavior that's being described might get the user to realize that malware has infected their machine and they'll repair it.

In your case, the system was doing you a favor. It was a false positive, yes, but that's because you're a reasonably intelligent person. My wife does ad-hoc tech support for a friend who isn't, and the anti-malware stuff in Windows (particularly Windows Defender) has saved the friends bacon at least three times this year alone.

On the other hand, you DO have a valid point: The dialog that was displayed by the firewall didn't give you enough information about what was happening. I believe that this is because you were operating under the belief that the Windows firewall was both an inbound and outbound firewall. The Windows Vista firewall IS both, but by default it's set to allow all outbound connections (you need to configure it to block outbound connections). If you were operating under the impression that it was an outbound firewall, you'd expect it to prompt for outbound connections.

People HATE outbound firewalls because of the exact same reason you're complaining - they constantly ask people "Are you sure you want to do that?" (Yes, dagnabbit, I WANT to let Firefox access the internet, are you stupid or something?).

IMHO outbound firewalls are 100% security theater[1][2]. They provide absolutely no value to customers. This has been shown time and time again (remember my comment above about applications being able to punch holes in the firewall? Malware can do the exact same thing). The only thing an outbound firewall does is piss off customers. If the Windows firewall was enabled to block outbound connections by default, I guarantee you that within minutes of that release, the malware authors would simply add code to their tools to disable it. Even if you were to somehow figure out how to block the malware from opening up outbound ports[3], the malware will simply hijack a process running in the context of the user that's allowed to access the web. Say... Firefox. This isn't a windows specific issue, btw - every other OS available has exactly the same issues (malware being able to inject itself into processes running in the same security context as the user running the malware).

Inbound firewalls have very real security value, as do external dedicated firewalls. I honestly believe that the main reason you've NOT seen any internet worms since 2002 is simply because XP SP2 enabled the firewall by default. There certainly have been vulnerabilities found in Windows and other products that had the ability to be turned into a worm - the fact that nobody has managed to successfully weaponize them is a testament to the excellent work done in XP SP2.

[1] I'm slightly overexaggerating here - there is one way in which outbound firewalls provide some level of value, and that's as a defense-in-depth measure (like ASLR or heap randomization). For instance, in Vista, every built-in service (and 3rd party services if they want to take the time to opt-in) defines a set of rules which describes the networking behaviors of the service (I accept inbound connections on UDP from port <foo>, and make outbound connections to port <bar>). The firewall is pre-configured with those rules and will prevent any access to the network from those services. The outbound firewall rules make it much harder for a piece of malware to make outbound connections (especially if the service is running in a restricted account like NetworkService or LocalService). It is important to realize this is JUST Defense-in-Depth measure and CAN be worked around (like all other defense-in-depth measures).

[2] Others disagree with me on this point - for example, Thomas Ptacek over at Matasano wrote just yesterday: "Outbound filtering is more valuable than inbound filtering; it catches “phone-home” malware. It’s not that hard to implement, and I’m surprised Leopard doesn’t do it." And he's right, until the "phone-home" malware decides to turn off the firewall. Not surprisingly, I also disagree with him on the value of inbound filtering.

[3] I'm not sure how you do that while still allowing the user to open up ports - functionality being undocumented has never stopped malware authors.

Every threat model diagram should tell a story.

LarryOsterman — Tue, 23 Oct 2007 01:14:38 GMT

Adam Shostack has another threat modeling post up on the SDL blog entitled "Threat Modeling Self Checks and Rules of Thumb". In it, he talks about threat models and diagrams (and he corrects a mistake in my "rules of thumb" post (thanks Adam)).

There's one thing he mentions that is really important (and has come up a couple of times as I've been doing threat model reviews of various components). That a threat model diagram should tell a story.

Not surprisingly, I love stories. I really love stories :). I love telling stories, I love listening to people telling stories.

I look for stories in the most unlikely of places, including places that you wouldn't necessarily think of.

So when I'm reviewing a threat model, I want to hear the story of your feature. If you've done a good job of telling your story, I should be able to see what you've drawn and understand what you're building - it might take a paragraph or two of text to provide surrounding context, but it should be clear from your diagram.

What are the things that help to tell a good story? Well, your story should be coherent. Stories have beginnings, middles and ends. Your diagram should also have a beginning (entrypoint), a middle (where the work is done) and an end (the output of the diagram). For example, in my PlaySound threat model, the beginning is the application calling PlaySound, the end is the audio engine. Obviously other diagrams have other inputs and outputs, but your code is always invoked by something, and it always does something. Your diagram should reflect this.

In addition, it's always a good idea to look for pieces that are missing. For instance, if you're doing a threat model for a web browser, it's highly likely that the Internet will show up somewhere in the model. If it doesn't, it just seems "wrong". Similarly, if your feature name is something like "Mumblefrotz user experience", then I'd hope to find something that looks like a "user" and something that looks like a "Mumblefrotz".

Adam's post calls out other inconsistencies that interfere with the storytelling, as does my "rules of thumb" post.

I really like the storytelling metaphor for threat model diagrams because if I can understand the story, it really helps me find the omissions - there's almost always something missed in the diagram, and a coherent story really helps to understand that. In many ways, pictures do a far better job of telling stories than words do.

Some final thoughts on Threat Modeling...

LarryOsterman — Mon, 01 Oct 2007 19:54:00 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah, I know I should have done this last week, but I got distracted :).

First, a summary of the threat modeling posts:

Part 1: Threat Modeling, Once again. In which our narrator introduces the idea of a threat model diagram

Part 2: Threat Modeling Again. Drawing the Diagram. In which our narrator introduces the diagram for the PlaySound API

Part 3: Threat Modeling Again, Stride. Introducing the various STRIDE categories.

Part 4: Threat Modeling Again, Stride Mitigations. Discussing various mitigations for the STRIDE categories.

Part 5: Threat Modeling Again, What does STRIDE have to do with threat modeling? The relationship between STRIDE and diagram elements.

Part 6: Threat Modeling Again, STRIDE per Element. In which the concept of STRIDE/Element is discussed.

Part 7: Threat Modeling Again, Threat Modeling PlaySound. Which enumerates the threats against the PlaySound API.

Part 8: Threat Modeling Again, Analyzing the threats to PlaySound. In which the threat modeling analysis work against the threats to PlaySound is performed.

Part 9: Threat Modeling Again, Pulling the threat model together. Which describes the narrative structure of a threat model.

Part 10: Threat Modeling Again, Presenting the PlaySound threat model. Which doesn't need a pithy summary, because the title describes what it is.

Part 11: Threat Modeling Again, Threat Modeling in Practice. Presenting the threat model diagrams for a real-world security problem .[1]

Part 12: Threat Modeling Again, Threat Modeling and the firefoxurl issue. Analyzing the real-world problem from the standpoint of threat modeling.

Part 13: Threat Modeling Again, Threat Modeling Rules of Thumb. A document with some useful rules of thumb to consider when threat modeling.

Remember that threat modeling is an analysis tool. You threat model to identify threats to your component, which then lets you know where you need to concentrate your resources. Maybe you need to encrypt a particular data channel to protect it from snooping. Maybe you need to change the ACLs on a data store to ensure that an attacker can't modify the contents of the store. Maybe you just need to carefully validate the contents of the store before you read it. The threat modeling process tells you where to look and gives you suggestions about what to look for, but it doesn't solve the problem. It might be that the only thing that comes out from your threat modeling process is a document that says "We don't care about any of the threats to this component". That's ok, at a minimum, it means that you considered the threats and decided that they were acceptable.

The threat modeling process is also a living process. I'm 100% certain that 2 years from now, we're going to be doing threat modeling differently from the way that we do it today. Experience has shown that every time we apply threat modeling to a product, we realize new things about the process of performing threat modeling, and find new, more efficient ways of going about the process. Even now, the various teams involved with threat modeling in my division have proposed new changes the process based on the experiences of our current round of threat modeling. Some of them will be adopted as best practices across Microsoft, some of them will be dropped on the floor.

What I've described over these posts is the process of threat modeling as it's done today in the Windows division at Microsoft. Other divisions use threat modeling differently - the threat landscape for Windows is different from the threat landscape for SQL Server and Exchange, which is different from the threat landscape for the various Live products, and it's entirely different for our internal IT processes. All of these groups use threat modeling, and they use the core mechanisms in similar ways, but because each group that does threat modeling has different threats and different risks, the process plays out differently for each team.

If your team decides to adopt threat modeling, you need to consider how it applies to your components and adopt the process accordingly. Threat Modeling is absolutely not a one-size-fits-all process, but it IS an invaluable tool.

EDIT TO ADD: Adam Shostak on the Threat Modeling Team at Microsoft pointed out that the threat modeling team has a developer position open. You can find more information about the position by going to here: http://members.microsoft.com/careers/search/default.aspx and searching for job #207443.

[1] Someone posting a comment on Bruce Schneier's blog took me for task for using a browser vulnerability. I chose that particular vulnerability because it was the first that came to mind. I could have just as easily picked the DMG loading logic in OSX or the .ANI file code in Windows for examples (actually the DMG file issues are in several ways far more interesting than the firefoxurl issue - the .ANI file issue is actually relatively boring from a threat modeling standpoint).

Banned APIs	StrSafe Replacement	Safe CRT Replacement
strlen, wcslen, _mbslen, _mbstrlen, StrLen, lstrlen	String*Length	strnlen_s