Tales from the Crypto : Programmer Hubris

White House moves to Open Source

Alun Jones — Tue, 27 Oct 2009 04:15:59 GMT

Subtitle: Media posts uninformed rubbish as commentary

From the MSNBC story “White House opens Web site coding to public”:

"Security is fundamentally built into the development process because the community is made up of people from all across the world, and they look at the source code from the very start of the process until it's deployed and after," said Terri Molini of Open Source for America, an interest group that has pushed for more such programs.

Expecting Open Source to be more secure because the general public contributes to and reviews it is like expecting a televised football match to be safer, because the folks at home are engaged in crowd control and looking for pickpockets.

While you might luck out in finding a few talented, devoted, and dare I say it, obsessed individuals who will call the police every time they see an infraction on screen, most of the people tuning in are going to be watching the game; and those that are trying to help are often clueless about how the security in the grounds works, and you’ll get many calls from people who see the security guards searching bags on entry as pickpockets.

Lots more to pick on

There’s lots more to pick on in the article – for instance, the inability to determine the difference between a content management system and the web site it serves (akin to not knowing the difference between a story and the typewriter on which it was written), which itself significantly reduces the need for this one Open Source product to be secure.

The news article barely hints at some of the true advantages of Open Source – that others can drop additional components in at their pleasure, and that you can pick up whichever of those components you need. [Of course, the same is true of closed source products with good published interface specifications, so perhaps this is only an advantage in the extreme case that the provided interfaces are incomplete.]

Is Open Source more or less secure?

There are plenty of reasons to believe that Open Source offers security advantages – it’s possible, for instance, to do your own deep security investigations and fix problems when you become aware of them. Of course, that’s rather like saying an advantage of buying an old car is that you get to do your own services – great if you’re a mechanic, not so good if you have to check the owner’s manual to remember which end to put petrol into.

Software is more secure because it is written by good, dedicated, experienced programmers, reviewed by other good, dedicated, experienced programmers, analysed by tools and experienced programmers looking for security flaws, and tested pretty much to destruction.

Don’t forget, as well, that there is little perceivable difference between secure software, lucky software, and uninteresting software. All will appear to be unhacked – until luck runs out, or the software becomes interesting to an attacker.

I don’t claim to be able to determine that all Open Source is more or less secure than all Closed Source.

Just that the “more eyeballs” line doesn’t remotely provide anything close to an explanation.

SAL-like code annotations for Java

Alun Jones — Wed, 21 Oct 2009 03:44:34 GMT

http://types.cs.washington.edu/jsr308/ seems to be talking about a set of type annotations for Java that are similar to those provided in Microsoft Visual C++ by SAL, the Standard Annotation Language.

One thing that the Java annotations have going for them over the SAL is that these annotations are going to be a part of the Java 7 standard, so it’s something that will come with the language no matter who implements it, whereas the C++ SAL extensions are specific to Microsoft. Of course, when I say “no matter who implements it”, I’m not aware of any significant currently supported implementations of Java outside of Sun, so it’s possible that such a statement is necessarily limited.

[Note that the SAL extensions can be included in C++ code that is compiled with other compilers, you just won’t see any benefit from them when using other compilers.]

What do annotations do?

As explained in the blog post that Michael Howard put out when SAL was first made available, these code annotations add something to object and function prototypes. What they add is the ability to turn run-time issues into compile-time errors.

So, for instance, a null pointer dereference, that would be an instant denial of service on your application, is trapped at compile time, because you declared in your function or class prototypes that you expect the pointer not to be null.

Adding these annotations to your code can certainly be a time-consuming task, since you have to revisit old code and add them in by had, recapturing assumptions that you had originally made about objects you reference. That in itself can be a learning experience, of course, and because you will capture a number of outstanding reliability, quality and security bugs, it’s far from being an empty investment.

What do the Java annotations capture?

The first checker that the Java annotations implement is the Nullness checker. This allows you to declare whether you are expecting a reference or value to be null or not. This generally avoids you seeing exceptions through dereferencing null.

The Interning checker prevents you from seeing poor results when comparing two objects (such as two instances of “Integer(2)”) using “==” or “!=”. Without the Interning checker, using “==” to compare two Integer variables each containing an instance of Integer(2) will produce the result ‘false’. This can cause logical processing errors, which the Interning checker will address.

The Mutability (IGJ or Javari) checker allows you to specify that an object reference should not be used to modify the contents of that object.

The Lock checker prevents locking errors by allowing you to declare that objects can only be accessed when guarded by a lock, or to declare that a function can only be called when holding a particular lock.

The Tainted checker allows you to mark an object as coming from an untrusted source (think “user”). Marking some functions as expecting Untainted data will prevent them from being fed Tainted data, and will ensure that other developers accessing such a function will call checking routines to convert the data from Tainted to Untainted before passing it to your functions.

The Linear checker prevents your code from holding more than one reference to objects marked as Linear. Since Java, like C#, likes to copy references to objects, rather than the objects themselves, this checker can prevent you from finding unexpected side-effects from objects being modified through aliases you weren’t expecting.

Further checkers appear to allow you to write your own checkers, but I haven’t got the Java programming chops to really play with these.

Should I include these annotations in my Java projects?

Definitely. Or something like them. Using annotations to define to the compiler some of the expectations you make of your code (a hyped-up interface contract, if you like) allows the compiler to check more deeply into whether those assumptions can hold true throughout your code.

My own experience of SAL-annotated code is that it has allowed me to discover some relatively subtle bugs in my programs. Or bugs that weren’t quite so subtle, but just weren’t jumping out at me.

A quick look at these Java annotations suggests that they will do the same for Java projects. Frankly, the more help you can get from these static analysis tools, the better. Analysis tools don’t catch all problems, and they aren’t a substitute for good programming, but they do provide a second check on your own assumptions that can be very useful.

Previous articles on SAL:

Sometimes It Seems Like Unix(*) Needs to Learn from Windows

Alun Jones — Sun, 27 Sep 2009 03:22:00 GMT

(*) By “Unix”, I mean Linux, Unix, AIX, OS/X, and similar flavours.

Way back when, about twenty or so years ago, I was a Unix admin, and a Unix developer. I had to be both, because I was the only person in the company who could spell Unix.

My favourite game was to go along to presentations for Microsoft Windows ‘new features’ and say “Oh, but hasn’t Unix had that for the last twenty years?”

Sure enough, there were countless things that Windows users and developers were just discovering (TCP/IP, shared libraries, multiple sessions on the same computer) that had been in Unix for some time. Linux was yet to make a mention, but as I’ve moved firmly into the Windows world, and left Unix behind, I’ve pretty much assumed that technologically speaking, if Windows has it, Unix and the like must also have the same functionality.

As I re-engage with Unix and Linux developers and IT professionals in recent months, though, I can see that there are some areas – particularly in security - where Windows is far ahead of the *x operating systems. Here’s a few:

Where’s my EFS?: EFS, the Encrypting File System, is one of Windows’ best-kept secrets. It’s not really a secret, of course, but it acts like one – there are so few people willing to use it, and mostly because they’re scared of or don’t understand it.; EFS allows users (under administrative control and with appropriate recovery measures in place) to choose files to encrypt, and to declare which other users can access the encrypted files.; EFS-encrypted files are encrypted on disk, and the keys cannot be broken simply by mounting an offline attack, because the key for each file is encrypted with users’ public keys, and the private keys are held securely in the users’ certificate store.; What does *x have in response? Whole disk encryption by third-party products (OK, Windows has Bitlocker and any number of third-party products). EFS protects individual files, and is far more fine-grained than the ‘all or nothing’ access of WDE (or FDE, Full Disk Encryption, if you prefer).
Single Certificate Store: This isn’t really a “single” store so much as a predictable location for the certificate store. If you want to read a user’s certificates and keys, you know where to find them (although you generally only have access if you are the user in question. Private keys from the certificate store are protected using the DPAPI, appropriately protecting them (apart from some key recovery scenarios, you have to log in using the password associated with the keys).; Similarly, certificates and keys belonging to the system and its service accounts are also in predictable locations.; This makes life easy for tools that need to scan for certificates due to expire.; Where are certificates and keys stored in *x? All over the place. Generally in “PEM” files, usually (but not always) in the same directory in which the application that installs them is.; How are these private keys protected in *x? There’s sometimes a password to open up the private key from the PEM file, and usually the PEM file has a restrictive access mask on it. [Read further for more problems with this]
Single SSL Library: It’s not uncommon to see several instances of OpenSSL installed on any particular system, whether it’s *x or Windows, if the system runs applications that use OpenSSL.; Windows developers, of course, can simply use the SSL API built in to Windows (CryptoAPI, CAPI and SChannel), and not have to worry about shipping an SSL library with their application, or keeping up with new versions as they come out, or tracking down customers and notifying them of updates to address security flaws (such as the Debian Linux key generation flaw I posted about a while ago).
Single SSL Configuration: If I want to disable SSL v2, or ciphers with fewer than 128 bits, on Windows I can change a few registry settings and know that I’ve fixed every application that uses SChannel. I can even do that remotely, with remote registry editing from a script or group policy tattooing the registry.; To do the same for OpenSSL, it seems that I have to find every application that uses OpenSSL and change the configuration files there.
Data Protection API and configuration file protection: This is the one that really started me on this article.; How do you store a password in a configuration file?; Yes, the ‘right’ security answer is “you don’t”, but that’s naive. The fact is that there are many instances wherein you have to store a password – to access and authenticate to a remote application, or (if you’re using OpenSSL) to open a password-protected PEM or PFX file in order to read out the private key.; On Windows, the Patterns and Practices team have documented how to do this – basically, you use the DPAPI to encrypt the password into the config file, and again to decrypt it back out – and your DPAPI keys are encrypted by your master key, which is derived from your password. The end result is that you can’t get those DPAPI keys without the password.; What do the *x platforms have?; ”Put the password in plain text, and protect it with a restrictive access mask”, is what I’m told. And in a search, I couldn’t find anything better being recommended. OK, one person recommended encoding the password with base64, but that’s hardly a security measure.; Jesper brought up the excellent question of “how is it different?” – in the *x system, the password is marked as only being accessible to the correct user. I was about to answer him when Steve F spoke up for me, and noted that in the DPAPI case, you have to read the file, and then an API has to be called to decrypt the password; in the *x case, you simply have to read the file. There are many many more exploits that allow the reading of a file under privileged rights than there are exploits that allow the execution of code.
Patch Management and Group Policy: Microsoft has done a really good job of implementing enterprise-level management features into their operating systems, from Group Policy and WMI to WSUS and other update management tools.; The *x systems I’ve seen seem to be built from the perspective that each system has its own attendant administrator, who is only too happy to manually deploy patches or tweak settings in line with some policy on a scrap of paper or post-it.

Maybe I’m missing some huge advances, and maybe some of these issues are resolved with a third-party tool – but then, maybe that’s part of the problem too. All of the above are a part of the operating system in Windows, and can be relied on to exist by developers, and their use by applications can be expected by IT professionals.

[Disclaimer: Yes, I know there are still areas where Microsoft needs to learn from Unix and Linux, and perhaps it’d be good if you’d educate me on those, too. This isn’t a “Windows is better than *X” debate, it’s a “hey, even if you think *X is better than Windows, here are some areas *X needs improving in”.]

Edit: There have been some excellent comments posted overnight in response to this article, and as I had hoped, I am mostly still 'in the dark' about what Linux and Unix-like systems offers. I'll be looking at these as I have time, and responding when I can. For now, just let me say that I am impressed to see so much technical content in the responses, and so little of the "fanboy" behaviour that often characterises these discussions.

The CWE Top 25 Programming Mistakes

Alun Jones — Thu, 22 Jan 2009 12:39:00 GMT

I’ve read some debate about the top 25 programming mistakes as documented by the CWE (Common Weakness Enumeration) project, in collaboration with the SANS Institute and the MITRE . That the list isn’t complete, that there are some items that aren’t in the list, but should be, or vice-versa.

I think we should look at the CWE top-25 as something like the PCI Data Security Standard – it’s not the be-all and end-all of security, it’s not universally applicable, it’s not even a “gold standard”. It’s just the very bare minimum that you should be paying attention to, if you’ve got nowhere else to start in securing your application.

As noted by the SANS Institute, the top 25 list will allow schools and colleges to more confidently teach secure development as a part of their classes.

I personally would like to see a more rigorous taxonomy, although in this field, it’s really hard to do that, because in large part it’s a field that feeds off publicity – and you just can’t get publicity when you use phrases like “rigorous taxonomy”. Here’s my take on the top 25 mistakes, in the order presented:

Insecure Interaction Between Components

“These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.”

CWE-20: Improper Input Validation

What’s proper input validation? Consider the thought that there is no input, no output, only throughput. A string is received at the browser, and turned into a byte encoding; this byte encoding is sent to the web server, and possibly re-encoded, before being held in storage, or passed to a processing unit. For every input, there is an output, even if it’s only to local in-memory storage.
Validating the input portion falls broadly into two categories – validating for length, and validating for content. Validating for length seems simple – is it longer than the output medium is expecting? You should, however, check your assumptions about an encoding – sometimes encodings will add, and sometimes they will remove, counts of the members of the sequence – and sometimes they may do both.
Validating for content can similarly be broken into two groups – validating for correctness against the encoding expected, and then validating for content as to “business logic” (have you supplied a telephone number with a square-root sign or an apostrophe in it, say). Decide whether to strip invalid codes, or simply to reject the entire transaction. Usually, it is best (safest) to reject the entire transaction.

CWE-116: Improper Encoding or Escaping of Output

The other part of “throughput validation” – and while we constantly tell programmers that they should refuse to trust input, that should not be held as an excuse to produce untrustworthy output. There are many times when your code is trusted to produce good quality output. Some examples:

When you write a web application visited by a user, that user trusts you not to forward other people’s code on to them. Just your own, and that of your business partners. [See Cross-Site Scripting, below]
When your application is used internally [See SQL Injection, below]

Be conservative in what you send – make sure it rigorously follows whatever protocol or design-time contract has been agreed to. And above all, when sending data that isn’t code, make sure to encode it so that it can’t be read as code!

CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')

SQL Injection is a throughput validation issue. In its essence, it involves an attacker who feeds SQL command codes into an interface, and that interface passes them on to a SQL database server.
This is almost an inexcusable error, as it is relatively easy to fix. The fix is usually hampered somewhat in that the SQL database server is required to trust the web server interface code, but that means only that the web server interface code must either encode, or remove, elements of the data that is being passed in the SQL command sequence being sent to the server. The most reliable way to do this is to use parameterised queries or stored procedures. Avoid building SQL commands through concatenation at almost any cost.

CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')

I hate the term “cross-site scripting”. It’s far easier to understand if you just call it “HTML injection”. Like SQL injection, it’s about an attacker injecting HTML code into a web page (or other HTML page) by including it as data, in such a way that it is provided to the user as code.
Again, a throughput content validation issue, anything that came in as data and needs to go out as a part of an HTML page should be HTML encoded, ideally so that only the alphanumerics are unencoded.

CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')

Like SQL injection, this is about generating code and including data. Don’t use your data as part of the generation of code.
There are many ways to fix this kind of an issue – my favourite is to save the data to a file, and make the code read the file. Don’t derive the name or location of the file from the user-supplied data.

CWE-319: Cleartext Transmission of Sensitive Information

What’s sensitive information? You decide, based on an analysis of the data you hold, and a reading of appropriate laws and contractual regulations. For example, with PCI DSS, sensitive information would include the credit card number, magnetic track data, and personal information included with that data. Depending on your state, personal contact information is generally sensitive, and you may also decide that certain business information is also sensitive.
Seriously, SSL and IPsec are not significant performance drains – if your system is already so overburdened that it cannot handle the overhead of encrypting sensitive data, you are ALREADY too slow, and only providence has saved you from problems.
Especially where the data is not your own, make an informed decision as to whether you will be communicating in clear text.

CWE-352: Cross-Site Request Forgery (CSRF)

Another confusing term, CSRF refers to the ability of one web page to send you HTML code that your browser will execute against another web page. This really is cross-site, and forges requests that look to come from the user, but really come from a web page being viewed in the user’s browser.
The fix for this is that every time you display a form (or even a solitary button, if that button’s effects should be unforgeable), you should include a hidden value that contains a random number. Then, when the “submit” (or equivalent) button is pressed, this hidden value will be sent back with the other contents of the form. Your server must, of course, validate this number is correct, and must not allow the number to be long-lived, or be used a second time. A simple fix, but one that you have to apply to each form.
This really falls under a category of guaranteeing that you are talking to the user (or the user’s trusted agent), and not someone pretending to be the user. Related to non-repudiation.

CWE-362: Race Condition

Race conditions refer to any situation in which the execution of two parallel threads or processes behaves differently when the order of execution is altered. If I tell my wife and son to go get a bowl and some flour, and to pour the flour into the bowl, there’s going to be a mess if my wife doesn’t get the bowl as quickly as my son gets the flour. Similarly, programs are full of occasions where a precedence is expected or assumed by the designer or programmer, but where that precedence is not guaranteed by the system.
There are books written on the topic of thread synchronisation and resource locking, so I won’t attempt to address fixing this class of issues.

CWE-209: Error Message Information Leak

Be helpful, but not too helpful. Give the user enough information to fix his side of the error, but not so much that he has the ability to learn sensitive information from the error message.
“Incorrect user name or password” is so much better than “Incorrect password for that user name”.
“Internal error, please call technical support, or wait a few minutes and try again” is better than “Buffer length exceeded at line 543 in file c:\dev\web\creditapp\cardcruncher.c”
Internal information like that should be logged in a file that is accessible to you when fixing your system, but not accessible to the general end users.

Risky Resource Management

“The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.”

CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer

The old “buffer overflow” – a throughput length validation issue. Any time you take data from one source and place it into another destination, you have to reliably predict whether the destination is large enough to hold it, and you also have to decide what you will do if it is not.
Don’t rely solely on .NET or Java “protecting you from buffer overruns” – when you try and access an element outside of a buffer’s limits, they will simply throw an exception – crashing your program dead in its tracks. This in itself could cause half-complete files or other communications, which could feed into and damage other processes. [And simply catching all exceptions and continuing blindly is something I’ve complained about before]

CWE-642: External Control of Critical State Data

By “Critical State Data”, this refers to information about where in the processing your user is. The obvious example of bad external control of critical state data is sending the price to the user, and then reading it back from the user. It obviously isn’t too hard from an attacker to simply modify the value before sending it to the server.
Other examples of poorly chosen state being passed includes the use of customer ID numbers in URLs, in such a way that it is obvious how to select a different customer’s number.
State data such as this should generally be held at the server, and a ‘reference’ value exchanged to allow the server to regain state when a user responds. If this value is populated among users sufficiently sparsely, it’s close to impossible for an attacker to steal someone else’s state.

CWE-73: External Control of File Name or Path

This is related to forced-browsing, path-traversal, and other attacks. The idea is that any time you have external paths (such as URLs) with a direct 1:1 relationship to internal paths (directories and paths), it is usually possible to pass path control from the external representation into the internal representation.
Make sure that all files requested can only come from a known set of files; disable path representations (such as “..”, for ‘parent directory’) that your code doesn’t actually make use of.
Instead of trying to parse the strings yourself to guess what file name the operating system will use, always use the operating system to tell you what file name it’s going to access. Where possible, open the file and then query the handle to see what file it really represents.

CWE-426: Untrusted Search Path

Windows’ LoadLibrary is the classic example of this flaw in design – although the implicit inclusion of the current directory in Windows’ execution PATH searched is another.
When writing programs, you can only trust the code that you load or call if you can verify where you are loading or calling it from.
A favourite trick at college was to place ‘.’ at the front of your path, add a malicious shell file called ‘rm’, and invite a system administrator to show you how to kill a print job. The “lprm” command he’d run would call “rm”, and would run the local version, rather than the real command. Bingo, instant credentials!
Don’t search for code that you trust – know where it is, and if it isn’t there, fail.

CWE-94: Failure to Control Generation of Code (aka 'Code Injection')

I find it hard to imagine the situation that makes it safe to generate code in any way based off user input.
Perhaps you could argue that this is what you do when you generate HTML that contains, as part of its display, user input. OK then, the answer here is to properly encode that which you embed, so that the code processor cannot become confused as to what is code and what is data.

CWE-494: Download of Code Without Integrity Check

Either review the code that you download, or insist that it is digitally signed by a party with whom you have contracted for that purpose. Otherwise you don’t know what you are downloading or what you are executing.

CWE-404: Improper Resource Shutdown or Release

This covers a large range of issues:

Don’t “double-free” resources. Make sure you meticulously enforce one free / delete for every allocation you make. Otherwise, you wind up releasing a resource that you wanted to hang onto, or you may crash your program.
If the memory you’re about to release (or file you’re about to close) contained sensitive information, make sure it is wiped before release. Verify in the release build that the optimiser hasn’t optimised away this wiping!
Make sure you release resources when they are no longer in use, so that there are no memory leaks or other resource overuse problems that will lead to your application becoming bloated and fragile.

CWE-665: Improper Initialization

Lazy languages like Javascript, where a mistype becomes an instant variable assignment, should be avoided.
Define all variables’ types – no “IMPLICIT INTEGER*4 (I-N)” (Am I showing my age?)
Put something into your variables, so that you know what’s there. Don’t rely on the compiler unless the compiler is documented to guarantee initialisation.
By “variable”, I mean anything that might act like a variable – stretches of memory, file contents, etc.

CWE-682: Incorrect Calculation

Again, a multitude of sins:

“should have used sin, but we actually used cos”
divide by zero – or some similar operation – that causes the program to halt
length validation / numeric overflow – in a single byte, 128 + 128 = 0

As you can see, a denial of service can definitely occur, as can remote execution (usually a result of calculating too short a buffer, as a result of numeric overflow, and then overflowing the buffer itself)
Don’t underestimate the possible results of just plain getting the answer wrong – cryptographic implementations have been brought to their knees (and resulted in approving untrustworthy access) because they couldn’t add up properly.

Porous Defenses

“The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.”

CWE-285: Improper Access Control (Authorization)

This one pretty much speaks for itself. There’s public parts of your application, and there’s non-public parts. Make sure that you have to provide authentication before crossing that boundary, and make sure that the user account verified in authentication is the one that’s used for authorisation to access resources.
Carry user authentication information around carefully, without letting it be exposed to other forms of attack, but also to make sure that the information is available the next time you need to authorise access to resources.

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Translation – get a crypto expert to manage your crypto. [Note – this is why I recommend using CryptoAPI rather than OpenSSL, because you have to be your own expert to use OpenSSL.]
New algorithms arise, and old ones become obsolete. In the case of cryptographic algorithms, obsolete means “no longer effectively cryptographic”. In other words, if you use an old algorithm, or a broken algorithm, or don’t use an existing algorithm the right way, your data isn’t as protected as you thought it was.
Where possible, use a cryptographic framework such as SSL, where the choice of cryptographic algorithms available can be adjusted over time to deal with changing realities.

CWE-259: Hard-Coded Password

If there’s a hard-coded password, it will be discovered. And when discovered, it will be disseminated, and then you have to figure out how to get the message out to all of your users that they can now be owned because of your application. Not an easy conversation to have, at a guess.
This is a “just don’t do it” recommendation, not a “do it this way” or “do it that way”.

CWE-732: Insecure Permission Assignment for Critical Resource

If a low-privilege user can lock, or corrupt, a resource that is required for high-importance transactions, you’ve created an easy denial-of-service.
If a low-privilege user can modify something that is used as a basis for trust assignments, there’s an elevation of privilege attack.
And if a low-privilege user can write to your code base, you’re owned.

CWE-330: Use of Insufficiently Random Values

Give me a random number. 7. Give me another random number. 7. And another? 7.
How do you tell if a number is random enough? You hire a mathematician to do a statistical analysis to see if the next number is predictable if you know any or all of the previous numbers.
This mostly ties into CWE-327, don’t do your own crypto if you’re not a crypto expert (and by the way, you’re not a crypto expert). However, if you’re hosting a poker web site, it’s pretty important to be able to shuffle cards in an unpredictable manner!
Remember that the recent Kaminsky DNS attack, as well as the MD5 collision issues, could have been avoided entirely by the use of unpredictable numbers.

CWE-250: Execution with Unnecessary Privileges

Define “unnecessary”? No, define “necessary”. That which is required to do the job. Start your development and testing process as a restricted user. When you run into a function that fails because of lack of privileges, ask yourself “is this because I need this privilege, or can I continue without?”
Too many applications have been written that ask for “All” access to a file, when they only need “Read”.
Too many applications demand administrator access when they don’t really need it. I’m talking to you, Sansa Media Converter.

CWE-602: Client-Side Enforcement of Server-Side Security

I’ve seen this one hundreds of times. “We prompt the user for their birth date, and we reject invalid day numbers”; “Where do you reject those?”; “In the user interface so it’s nice and quick”. Great, so I can go in and make a copy of your web page, delete the checks, and input any number I like. Don’t consider it impossible that an attacker has written his own copy of the web browser, or can interfere with the information passing through the network.

What’s missing?

Glaringly absent, as usual, is any mention of logging or auditing.

Protections will fail, always, or they will be evaded. When this happens, it’s vital to have some idea of what might have happened – that’s impossible if you’re not logging information, if your logs are wiped over, or if you simply can’t trust the information in your logs.

Maybe I say this because my own “2ndAuth” tool is designed to add useful auditing around shared accounts that are traditionally untraceable – or maybe it’s the other way around, that I wrote 2ndAuth, because I couldn’t deal with the fact that shared accounts are essentially unaudited without it?

Of course, that leads to other subtleties – the logs should not provide interesting information to an attacker, for instance, and you can achieve this either by secreting them away (which makes them less handy), or by limiting the information in the logs (which makes them less useful).

Another missing issue is that of writing software to serve the user (all users) – and not to frustrate the attacker. [Some software reverses the two, frustrating the user and serving the attacker.] We developers are all trained to write code that does stuff – we don’t tend to get a lot of instruction on how to write code that doesn’t do stuff.

Another mistake, though it isn’t a coding mistake as such, is the absence of code review. You really can’t find all issues with code review alone, or with code analysis tools alone, or with testing alone, or with penetration testing alone, etc. You have to do as many of them as you can afford, and if you can’t afford enough to protect your application, perhaps there are other applications you’d be better off producing.

Other mistakes that I’d like to face head-on? Trusting the ‘silver bullet’ promises of languages and frameworks that protect you; releasing prototypes as production, or using prototype languages (hello, Perl, PHP!) to develop production software; feature creep; design by coding (the design is whatever you can get the code to do); undocumented deployment; fear/lack of dead code removal (“someone might be using that”); deploy first, secure later; lack of security training.

“Fully Stealthed” means fully spoofable

Alun Jones — Wed, 21 Jan 2009 00:50:19 GMT

Every so often, someone on one of the security mailing lists to which I subscribe will post a frothing rant from someone who has discovered their own personal “magic bullet” which solves all their security woes. This time, it’s a guy who was convinced that Microsoft’s recent out-of-band Internet Explorer patch MS08-078 is actually a conspiracy by Microsoft (and the government, of course) to invade your computer.

Okay, now aside from the point that, technically, Microsoft “pwns” your computer if you run their OS, and they don’t need to install patches to continue to do so; aside from the Ballmer defence (“If we were actually evil, don’t you think we’d be doing a better job at it?”; aside from that and many other considerations, what evidence did this guy have that the patch is a conspiracy?

Gibson Research’s ShieldsUp site reported that his system was “Fully Stealthed”.

[For those of you non-geeks reading the blog, that means that his firewall was closed up so tight that his system was not responding to any attempt to connect.]

Many other people have made, or will make, the obvious note that the patch is for a browser client bug, whereas the firewall ignoring all incoming requests only protects against server-related bugs, so I’ll leave it to those people to discuss that.

My concern is that Gibson is still pitching the idea that “Fully Stealthed” is a good idea.

TCP/IP, the network protocol on which much of the Internet is currently based, is designed around certain error reporting mechanisms that keep the system able to route around trouble.

One of these mechanisms is the TCP RST (reset) flag. The reset flag a great tool, as it says in a single bit “I received this packet, but I can completely guarantee that it’s not meant for me”. Another similar mechanism is the “ICMP Host Unreachable” response, which says “You appear to be trying to send a packet through me to another machine, but although I’m not a bad place to send that packet through, I can’t seem to reach that machine just now”.

When you’re “Fully Stealthed” (or completely non-responsive, if you prefer), it’s like you’re a black hole, and neither the TCP RST flag nor the ICMP Host Unreachable errors are returned from your system.

That’s great, right, because it means that your attackers can’t tell you’re there? It’s like you’re a black hole, no one can see you, right?

That sounds good in theory, except that even black holes can be seen, because they don’t act like the empty space that might otherwise be there.

Similarly, a “Fully Stealthed” machine gives away its presence by occupying an IP address that will not respond at all when you try to contact it. Very much like a black hole, it’s clear that it’s there, because if there was nothing there, the upstream routers would be passing back ICMP Unreachable messages.

OK, so maybe they know that I’ve got a machine here, at this IP address, but it’s safe, because it’s Fully Stealthed – Stealth just sounds so cool, especially since it’s a verbed noun! It’s alright that I look like a hole to the rest of the Internet, because nobody can do anything to me!

Wrong again.

The attacker can pretend to be you, because there’s nothing you’re going to say about it.

Let me qualify that – of course, the attacker can’t use your password if he doesn’t know it, nor can he use your private keys. But he can use another thing that some sites use as part of the proof that you are who you claim to be.

He can use your IP address.

A few things prevent this normally:

The attacker never gets to see responses to his traffic – but for the most part, he may be able to guess these, and perhaps he can see those responses, if he’s sniffing your line, for example.
You get to see the responses to the attacker – this allows your computer to say “I received this packet, but I can completely guarantee that it’s not meant for me” – in other words, to send a RST back.
If the attacker can’t see his responses, he needs to guess the random sequence number that is supplied in the SYN-ACK packet. Again, this isn’t a problem for the attacker if he’s sniffing your line, but it’s also not a problem for the attacker if he can guess the sequence number somewhat reliably. This happens every now and again, as network stack developers fail to predict ways in which their own randomness can be predicted.

So, number 1 and 3 aren’t always a barrier – number 2 is definitely a barrier if the attacker needs to maintain the connection for more than a few fractions of a second, as the RST from the spoofed IP address will cause the server to drop the connection and ignore what the attacker is trying to do.

So, this is a valuable protection that a “fully-stealthed” firewall is going to throw away for you – the ability to spot when someone is spoofing your IP address, and to respond back to say “uh, that isn’t me – stop talking to him”.

A firewall should behave as if the machine is present but disinterested, and should actively refuse misguided connection attempts and responses, not merely ignore them. There’s a big difference between the two behaviours. Don’t use the sensationalist terminology of a poor substitute for an expert as a replacement for understanding of your risks and threats.

Running out of disk space? How’s your logs?

Alun Jones — Thu, 25 Dec 2008 21:52:25 GMT

I ran out of disk space today.

This is not entirely a new issue for me, because I like to listen to BBC Radio from back home, and my only way to do that is to download the shows overnight so I can listen to them the next day. [I’m not allowed that sort of bandwidth at work]

I start troubleshooting this in the obvious way – where are my largest individual files, and are they useful? Windows Vista’s Search is great for this – you can ask for files over a certain number of bytes:

Whoa, over a gigabyte in that mysterious file called “setupapi.app.log”? Ah, but it’s in that C:\Windows\inf directory that I really shouldn’t mess with, so I’d better check to see that it’s alright to get rid of the file. Let’s see what the Microsoft Support Knowledge Base has to offer on the subject of huge files created by the Setup API.

http://support.microsoft.com/default.aspx/kb/958909 - “It may take a long time to log on to a Windows Vista-based computer that has antivirus software installed” – well, I haven’t really noticed that logons are that slow, and I don’t actually have antivirus software installed. But visiting the article, I see that this is only the first half of the title. The full title is:

It may take a long time to log on to a Windows Vista-based computer that has antivirus software installed, and you may notice that the file size of the Setupapi.app.log file is very large

So, to use a medical metaphor here, the large setupapi.app.log is the internal haemorrhaging caused by some injury or illness, and the slow logon (or in my case, the inability to use my disk space) is the externally visible symptom – the loss of consciousness, the fainting fit, the going-into-shock. Now that we’ve got the diagnosis, let’s see if the KB article has anything useful to say.

“This problem occurs because the verbose logging policy for the Setupapi.app.log file in Windows Vista is set to the most verbose setting (0x20000FFFF).

“…

“To work around this problem, remove or adjust the value of the following registry entry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\LogLevel”

Hmm… my value is set to 0x20000000. What value should it be?

“Type 0x00000020 in the Value data box.”

OK, that’s a little pedantic – instead, how about you click the “Hexadecimal” radio button, and enter “20”:

There is a hotfix mentioned in the article, but I rarely like to apply hotfixes to my machine if I am sure that the workaround will suffice. I may revisit the hotfix if I can’t see this work to reduce my log file size.

So, how did this happen? How did the setting get put to such a bizarre value?

Quite frankly, I don’t know – and as long as the problem goes away, I’ll just put it down to one of the many programs that I’ve installed or uninstalled. Judging from the fact that this log seems to have been in detail mode ever since November 2007, it’s likely that this setting was chosen (either by me or Microsoft) to gauge how successful the new install of Vista was going.

I now have a gigabyte of my file-space left, and I can go and download “Crisp and Even, Brightly”, one of my favourite Christmas shows from Radio 4. I only wish I could get the TV, because there are some excellent BBC shows that never make it across to this side of the Atlantic – and I just can’t wait for Doctor Who Season 4 – the next Doctor (or is he?), Cybermen, and a Victorian Christmas.

HTML Help in MFC

Alun Jones — Mon, 13 Oct 2008 04:36:11 GMT

I recently got around to converting an old MFC project from WinHelp format to HTML Help. Mostly this was to satisfy customers who are using Windows Vista or Windows Server 2008, but who don’t want to install WinHlp32 from Microsoft. (If you do want to install WinHlp32, you can find it for Windows Vista or Windows Server 2008 at Microsoft’s download site.]

Here’s a quick round trip of how I did it:

1. Convert the help file – yeah, this is the hard part, but there are plenty of tools, including Microsoft’s HTML Help Editor, that will do the job for you. Editing the help file in HTML format can be a little bit of a challenge, too, but many times your favourite HTML editor can be made to do the job for you.

2. Call EnableHtmlHelp() from the CWinApp-derived class’ constructor.

3. Remove the line ON_COMMAND(ID_HELP_USING, CWinApp::OnHelpUsing), if you have it - there is no HELP_HELPONHELP topic in HTML.

4. Add the following function:

void CWftpdApp::HelpKeyWord(LPCSTR sKeyword)
{
    HH_AKLINK akLink;
    switch (GetHelpMode())
    {
    case afxHTMLHelp:
        akLink.cbStruct = sizeof(HH_AKLINK);
        akLink.fReserved=FALSE;
        akLink.fIndexOnFail=TRUE;
        akLink.pszKeywords=sKeyword;
        akLink.pszMsgText=(CString)"Failed to find information in the help file on " + sKeyword;
        akLink.pszMsgTitle="HTML Help Error";
        akLink.pszWindow=NULL;
        AfxGetApp()->HtmlHelp((DWORD_PTR)&akLink,HH_KEYWORD_LOOKUP);
        break;
    case afxWinHelp:
        AfxGetApp()->WinHelp((long)(char *)sKeyword,HELP_KEY);
        break;
    }
}

5. Change your keyword help calls to call this new function:

((CWftpdApp *)AfxGetApp()->WinHelp((long)(char *)"Registering");

Becomes:

HelpKeyWord("Registering",HELP_KEY);

6. If you want to trace calls to the WinHelp function to watch what contexts are being created, trap WinHelpInternal:

void CWftpdApp::WinHelpInternal(DWORD_PTR dwData, UINT nCmd)
{
TRACE("Executing WinHelp with Cmd=%d, dwData=%d (%x)\r\n",nCmd,dwData,dwData);
CWinApp::WinHelpInternal(dwData,nCmd);
}

This trace comes in really, really (and I mean REALLY) handy when you are trying to debug “Failed to load help” errors. It will tell you what numeric ID is being used, and you can compare that to your ALIAS file.

7. If your code gives a dialog box that reads:

---------------------------
HTML Help Author Message
---------------------------
HH_HELP_CONTEXT called without a [MAP] section.
---------------------------
OK
---------------------------

What it means is that the HTML Help API could not find the [MAP] or the [ALIAS] section - without an [ALIAS] section, but with a [MAP] section, this message still will appear.

8. Don’t edit the ALIAS or MAP sections of your help file in HTML Help Editor – Microsoft has a long-standing bug here that makes it crash (losing much of your unsaved work, of course) unpredictably when editing these sections. Edit the HHP file by hand to work on these sections.

9. Most of your MAP section entries are automatically generated by the compiler, as .HM files, which hold macros appropriate for the specific control in the right dialog. Simply include the right HM file, and all you will need to do is create the right ALIAS mappings.

10. The MFC calls to HtmlHelp discard error returns from the function, so there’s really no good troubleshooting to go on when debugging access to help file entries.

Let me know if any of these helpful hints prove to be of use to you, or if you need any further clarification.

My MP3 player demands to administer my system

Alun Jones — Tue, 26 Aug 2008 06:22:35 GMT

Thanks to the excellent http://www.woot.com, I upgraded to a new MP3 player - this one, the Sansa e250 from SanDisk, has a little screen and shows video at an almost completely unacceptably small resolution. But I don't mind that, I didn't really buy it for the video. I don't mind the big fat "REFURB" label stuck on the back, nor do I really mind all that much that it's already lost a screw from the back.

What I do mind is that the developers of the software accompanying this player haven't figured out that I might want to use it as a consumer device, rather than an Information Technology Administration Tool. Quite honestly, I can't see how a media player - even if you count its ability to do video the size of my thumb - can be used to administer my system, but clearly that's the intent of the designers, because the software all insists on running as administrator.

The software at fault is at least the following:

Sansa Dispatcher - runs at logon, insists on running as administrator, therefore gets blocked on my Vista system. I'm still not quite sure what it's supposed to do, because I can use the Sansa acceptably well without this tool running, and when I do run it unblocked as admin, it does nothing more useful than causing my laptop to repeatedly crash with a blue-screen of death. Not very impressive.
Sansa Media Converter - allegedly this is required to put photos and videos onto the device - this, too, requires that I run it as an administrator (why? all it's supposed to do is convert movies and graphics from one format to another, and then copy them to the USB drive that the Sansa pretends to be when plugged in)
As if that wasn't infuriating enough, the Sansa Media Converter requires Apple QuickTime, my old nemesis. Yes, that means I'm back on the Apple Update thrill-ride to distraction.

It almost makes me want to wipe the firmware in the device and replace it with the Open Source software "Rock Box". Maybe then I can use ordinary tools to move my media onto the device, as an ordinary user.

We developers clearly have a loooong way to go before we grasp this concept that "administrator means the guy who makes changes to the configuration of the operating system", and "standard user means the guy who spends his life actually using the operating system".

I would love to be able to sort this out with technical support, but they insist on not talking to me in email, but requiring me to log on to a third party "eBox" from "customernation.com" - which sends out exhortations to visit your eBox as soon as Sansa's support has put a message in it. These invites come with your user name and password - over unencrypted email. Nice.

I'd tell you what's in my eBox, and what Sansa's support said, but I haven't been able to keep a connection up long enough for the painfully slow customernation.com web site to actually display anything. This is not a pleasant customer experience.

Searching for Weak Debian / Ubuntu SSL Certificates

Alun Jones — Fri, 23 May 2008 03:02:00 GMT

I've seen a number of people promote packages that have shipped for Debian and Ubuntu, which allow users to scan their collected keys - OpenSSH or OpenSSL or OpenVPN, to discover whether they're too weak to be of any functional use. [See my earlier story on Debian and the OpenSSL PRNG]

These tools all have one problem.

They run on the Linux systems in question, and they scan the certificates in place.

Given that the keys in question could be as old as 2 years, it seems likely that many of them have migrated off the Linux platforms on which they have started, and onto web sites outside of the Linux platform.

Or, there may simply be a requirement for a Windows-centric security team to be able to scan existing sites for those Linux systems that have been running for a couple of years without receiving maintenance (don't nod like that's a good thing).

So, I've updated my SSLScan program. I'm attaching a copy of the tool to this blog post, (along with a copy of the Ubuntu OpenSSL blacklists for 1024-bit and 2048-bit keys if I can get approval), though of course I would suggest keeping up with your own copies of these blacklists. It took a little research to find out how to calculate the quantity being used for the fingerprint by Debian, but I figure that it's best to go with the most authoritative source to begin with.

Please let me know if there are other, non-authoritative blacklists that you'd like to see the code work with - for now, the tool will simply search for "blacklist.RSA-1024" and "blacklist.RSA-2048" in the current directory to build a list of weak key fingerprints.

I've found a number of surprising certificates that haven't been reissued yet, and I'll let you know about them after the site owners have been informed.

[Sadly, I didn't find https://whitehouse.gov before it was changed - its certificate is shared with, of all places, https://www.gov.cn - yes, the White House, home of the President of America, is hosted from the same server as the Chinese government. The certificate was changed yesterday, 2008/5/21. https://www.cacert.org's certificate was issued two days ago, 2008/5/20 - coincidence?]

My examples are from the web, but the tool will work on any TCP service that responds immediately with an attempt to set up an SSL connection - so LDAP over SSL will work, but FTP over SSL will not. It won't work with SSH, because that apparently uses a different key format.

Simply run SSLScan, and enter the name of a web site you'd like to test, such as www.example.com- don't enter "http://" at the beginning, but remember that you can test a host at a non-standard port (which you will need to do for LDAP over SSL!) by including the port in the usual manner, such as www.example.com:636.

If you're scanning a larger number of sites, simply put the list of addresses into a fie, and supply the file's name as the argument to SSLScan.

Let me know if you think of any useful additions to the tool.

Here is some slightly modified output from a sample run of the tool (the names have been changed to protect the innocent):

The text to look for here is ">>>This Key Is A Weak Debian Key<<<".

Debian and the OpenSSL PRNG

Alun Jones — Fri, 16 May 2008 00:55:01 GMT

[PRNG is an abbreviation for "Pseudo-Random Number Generator", a ~~key~~ core component of the key-generation in any cryptographic library.]

A few people have already commented on the issue itself - Debian issued, in 2006, a version of their Linux build that contained a modified version of OpenSSL. The modification has been found to drastically reduce the randomness of the keys generated by OpenSSL on Debian Linux and any Linux derived from that build (such as Ubuntu, Edubuntu, Xubuntu, and any number of other buntus). Instead of being able to generate 1024-bit RSA keys that have a 1-in-2^1024 chance of being the same, the Debian build generated 1024-bit RSA keys that have a 1-in-2^15 chance of being the same (that's 1 in 32,768).

Needless to say, that makes life really easy on a hacker who wants to pretend to be a server or a user who is identifed as the owner of one of these keys.

The fun comes when you go to http://metasploit.com/users/hdm/tools/debian-openssl/ and see what the change actually was that caused this. Debian fetched the source for OpenSSL, and found that Purify flagged a line as accessing uninitialised memory in the random number generator’s pre-seeding code.

So. They. Removed. The. Line.

I thought I’d state that slowly for dramatic effect.

If they’d bothered researching Purify and OpenSSL, they’d have found this:

http://rt.openssl.org/Ticket/Display.html?id=521&user=guest&pass=guest

Which states (in 2003, three years before Debian applied teh suck patch) “No, it's fine - the problem is Purify and Valgrind assume all use of uninitialised data is inherently bad, whereas a PRNG implementation has nothing but positive (or more correctly, non-negative) things to say about the idea.”

So, Debian removed a source of random information used to generate the key. Silly Debian.

But there's a further wrinkle to this.

If I understand HD Moore's assertions correctly, this means that the sole sources of entropy (essentially, "randomness") for the random numbers used to generate keys in Debian are:

The Process ID (from 1 to 32,767)
The contents of an uninitialised area in the process' memory
uh... that's it.

[Okay, so that's not strictly true in all cases - there are other ways to initialise randomness, but these two are the fallback position - the minimum entropy that can be used to create a key. In the absence of a random number source, these are the two things that will be used to create randomness.]

If you compile C++ code using Microsoft's Visual C++ compiler in DEBUG mode, or with the /GZ, /RTC1, or /RTCs flags, you are asking the compiler to automatically initialise all uninitialised memory to 0xcc. I'm sure there's some similar behaviour on Linux compilers, because this aids with debugging accidental uses of uninitialised memory.

But what if you don't set those flags?

What does "uninitialised memory" contain?

It would be bad if "uninitialised memory" contained memory from other processes - previous processes that had owned memory but were now defunct - because that would potentially mean that your new process had access to secrets that it shouldn't.

So, "uninitialised memory" has to be initialised to something, at least the first time it is accessed.

Is it really going to be initialised to random values? That would be such a huge waste of processor time - and anyway, we're looking at this from the point of view of a cryptographic process, which needs to have strongly random numbers.

No, random would be bad. Perhaps in some situations, the memory will be filled with copies of 'public' data - environment variables, say. But most likely, because it's a fast easy thing to do, uninitialised memory will be filled with zeroes.

Of course, after a few functions are called, and returned from, and after a few variables are created and go out of scope, the stack will contain values indicative of the course that the program has taken so far - it may look randomish, but it will probably vary very little, if any, from one execution of the program to another.

In the absence of a random number seed file, or a random number generator providing /dev/urand or /dev/random, then, an OpenSSL key is going to have a 1 in 32,768 chance of being the same as a key created on a similar build of OpenSSL - higher, if you consider that most PIDs fall in a smaller range.

So, here's some lessons to learn about compiling other people's cryptographic code:

Don’t ever compile cryptographic code in release mode, because you will optimize away lines that clear secrets from memory.
Don’t ever compile cryptographic code in debug mode, because you will initialize memory that is expected to be uninitialised and random.
Don't ever modify cryptographic code, even if it throws up warnings. You don't understand what you're doing.
Don’t ever compile cryptographic code, because you don’t know what you are doing.

Why I use CryptoAPI

This is one reason why I prefer to use Microsoft's CryptoAPI, rather than libraries such as OpenSSL. There are others:

It's not my fault if something goes wrong with the crypto.
The users will apply patches to the crypto, and I don't have to go persuading my users to apply the patches.
There's a central place where administrators will expect to find crypto keys, and it's well-protected.
The documentation for CryptoAPI is far better than the documentation for OpenSSL, which is at best confusing, and at worst, non-existent.

In fairness, there are reasons not to use CryptoAPI:

New algorithms are made available for new versions of Windows, and not backported readily to older versions. With a library you ship, you get to decide which version customers can run - unless someone else comes and installs another version.
Microsoft's documentation is better, but it's still not perfect. Once in a while, it's not even correct. At least if you have the source code, and are insanely motivated, you can find out what the truth of a matter is.

We'll still be learning lessons for a while...

The lessons to learn from this episode are almost certainly not yet over. I expect someone to find in the next few weeks that OpenSSL with no extra source of entropy on some operating system or family of systems generates easily guessed keys, even using the "uninitialised memory" as entropy. I wait with 'bated breath.

Apple Changes Update Policies - Still No Biscuit

Alun Jones — Sat, 10 May 2008 04:32:34 GMT

As I have mentioned in other posts (Retro-bundling - another suck of the Apple, MacBook Air debuts; iTunes Pesters Me Again, Removing Apple Mobile Device Support, I didn't want iTunes - now I've got iPod, too?, etc, etc), this has long since stopped being an issue for me, because I've removed all the Apple software from my machine as a bit of a protest against Apple's inability or unwillingness to provide me the means to manage my own systems.

Now, I understand that Apple has finally heard some of the complaints from various blogs around the world, and has done something about it.

They have separated the updates from the new software. The new dialog looks like this:

But it still marks the new software by default to be installed.

This is the behaviour that is wrong - okay, so it's now clear as to the difference between an update and a new software, but the key again is that Apple is marking new software for installation from an update tool.

An update tool should be a piece of software that most users say "yes, do whatever", and that doesn't then cause significant additions to the software. By automatically checking new software, Apple is eroding the trust that users will have in the update tool.

Again, I don't mind that they're encouraging users to install Safari - I don't even mind them spending time persuading their existing install base to use it. What I'm perplexed at is that Apple feels that they have to slide it in under the door, rather than sell it to users on its own merits.

And, yes, I'm quite well aware that you could also say the same of any browser that ships with an operating system - except, really, you've got to have a browser shipping in your operating system these days. Yeah, the guys who ship the operating system have an advantage - and they worked hard to build that advantage in the first place. They have a certain momentum behind anything they offer, and even if the system is as open and transparent to all application vendors as it is to the OS vendor, the default installed applications will generally have a larger market share than the 'after-market' tools, just because of users' inertia.

[Note that the paragraph above applies to Apple / Mac / Safari, just as well as it does to Microsoft / Windows / Internet Explorer]

However, I don't think that users' inertia is a cause for sleight-of-hand tactics like retro-bundling.

Think like a bad guy? It's a start.

Alun Jones — Wed, 07 May 2008 00:33:57 GMT

Cool new site (and blog) from Microsoft - http://securedeveloper.com - and it has a tag line I've heard many times before:

Like that old maxim that "you need to stop fighting fires long enough to tell the architects to stop building things out of wood", thinking like a bad guy is just the first step to developer security.

It's a necessary step, but it's not the final goal.

It's a start - in fact, it's a great start, and I think every developer needs to go through that phase. Many have yet to do so - particularly, it seems, those fresh out of college or programming school.

But I think it's really a catch-phrase for the beginning of becoming a secure developer. It's what you have to tell yourself when you're used to writing code for the sole purpose of implementing features, so that you can get over that mind-set and into the sort of thinking that accepts that your code can be attacked.

But the bad guy has it easy.

He only has to find one way in. He can afford to become an expert on one part of your software, and zero in on it.

Thinking like a bad guy will widen your awareness to the point that you know that incursions can and will happen, and you'll occasionally take better care in your coding. That's a good thing.

But what if you start thinking like someone building a defensive structure?

The defence builder has to find (and limit) all the ways in, and just in case he missed one, he has to find all the ways you can get further in once you're in - he has to become an expert on all parts of the software, as well as something of an expert on the external dependencies - libraries, network equipment, database components, etc.

[After all, we've seen this past week how many sites can get exploited through SQL Injection attacks - and the primary cause for those seems to be web developers who don't know SQL, yet who send SQL statements to be executed at the database.]

You could start thinking like a defender - what alarms should signal the presence, or possibility, of an intruder? What information could an active defender use to verify the intent of a potential intruder? How could you slow down a possible attacker to the point where it's feasible for a human responder to outpace a mechanical attacker?

Maybe you could start thinking like an investigator - once you believe someone has got in, what clues would you like to be left, showing you where the holes were? How can you tell what defences have been useful and what defences were useless? Where was the attacker actively assisted or resisted by your system and software?

Perhaps you could even think like a defence component builder - how can you ensure that you learn lessons from tried and true defences in order to build those lessons in to the next system, or to teach the next set of builders?

Think like the architect of a mediaeval castle - we've gotten used to the idea that mediaeval castles were places of defence, that they sought to be impenetrable bastions behind which the local king, thane, lord or whatever could take refuge and survive. Yet they were also places of business, places of government, places with a function. We need to design programs like mediaeval castles - capable of functioning for business as well as for defence.

SecureDeveloper.com hasn't really gone beyond the first stage of its launch yet, so it will be a while before these advanced topics will be discussed - and I am eager to see that happen.

Can You Write Good Code for an OS you Despise?

Alun Jones — Sat, 03 May 2008 23:57:20 GMT

No, this isn't another of my anti-Mac frothing rants.

This is one of my "here's what I hate about many of the open-source projects I deal with" rants.

I'm trying to find an SFTP client for Windows that works the way I want it to.

All I seem to be able to find are SFTP clients for Unix shoe-horned in to Windows.

[Perhaps the Unix guys feel the same way about playing Halo under Wine.]

What do I mean?

Here's an example - Windows has a certificate store. It's well-protected, in that there haven't been any disclosures of significant vulnerabilities that allow you to read certificates without first having got the credentials that would allow you to do so.

So, I want an SFTP client that lets me store my private keys in the Windows certificate store. Or at least, that uses DPAPI to protect its data.

Can't find one.

Can't find ONE. And I'm known for being good at finding stuff.

PuTTY is recommended to me. It, too, requires that the private key be stored in a file, not in the certificate store. Its alternative is to use its own certificate store, called Pageant (it's an authorization "Age-Ant" for PuTTY, get it?) Maybe I could do something with that - write a variant of Pageant that directly accesses certificates stored in the certificate store.

But no, there's no protocol definition or API, or service contract that I can see in the documentation, that would allow me to rejigger this. I could edit the source code, but that's an awful lot of effort compared to building a clean implementation of only those parts of the API that I'd need.

What I do find in the documentation for Pageant are comments such as these:

Windows unfortunately provides no way to protect pieces of memory from being written to the system swap file. So if Pageant is holding your private keys for a long period of time, it's possible that decrypted private key data may be written to the system swap file, and an attacker who gained access to your hard disk later on might be able to recover that data. (However, if you stored an unencrypted key in a disk file they would certainly be able to recover it.)
Although, like most modern operating systems, Windows prevents programs from accidentally accessing one another's memory space, it does allow programs to access one another's memory space deliberately, for special purposes such as debugging. This means that if you allow a virus, trojan, or other malicious program on to your Windows system while Pageant is running, it could access the memory of the Pageant process, extract your decrypted authentication keys, and send them back to its master.

I'll address the second comment first - it's a strange way of noting that Windows, like other modern operating systems, assumes that every process run by the user has the same access as the user. Typically, this is addressed by simply minimising the amount of time that a secret is held in memory in its decrypted form, and using something like DPAPI to store the secret encrypted.

The first comment, though, indicates a lack of experience with programming for Windows, and an inability to search. Five minutes at http://msdn.microsoft.com gets you a reference to VirtualLock, which allows you to lock 4kB at a time into physical memory, aka non-paged pool. Of course, there are other options - encrypting the Pagefile using EFS also helps protect against this kind of attack, and the aforementioned trick of holding the secret decrypted in memory for as short a time as possible also reduces the risk of having it exposed.

Now I'm really stretching to assert that this single author despises Windows and that's why he's completely unaware of some of its obvious security features and common modes of use. But it does seem to be a trend prevalent in some of the more religious of open source developers - "Windows sucks because it can't do X, Y and Z" - without actually learning for certain whether that's true. Often, X and Y can be done, and Z is only necessary on other operating systems due to quirks of their design.

Back when I first started writing Windows server software, the same religious folks would tell me "don't bother writing servers for Windows - it's not stable enough". True enough, Windows 3.1 wasn't exactly blessed with great uptime. But instead of saying "you can't build a server on Windows", I realised that there was a coming market in Windows NT, which was supposed to be server class. So I wrote for Windows NT, I assumed it was capable of server functionality, and any time I felt like I'd hit a "Windows can't do this", I bugged Microsoft until they fixed it.

Had I simply walked away and gone to a different platform, I'd be in a different place - but my point is that if you believe that your target OS is incapable, you will find it to be so. If you believe it should be capable, you will find it to be so.

Retro-bundling - another suck of the Apple

Alun Jones — Sat, 22 Mar 2008 04:15:47 GMT

I thought I was done blogging about Apple Software Update, having removed QuickTime from my system completely, and sworn never to install it again or watch another QT or MOV file.

But nooo, someone had to spoil it by telling me what Apple Software Update did next.

If you're unfortunate enough to have QuickTime installed with Apple Software Update, you'll already have seen it.

Not only is Apple going to offer you iTunes and QuickTime as an "update" (despite you not actually having iTunes installed in the first place), they're also going to offer you Safari, the feature-light Apple web browser, as an "update" (again, even though you haven't installed it). And they're going to check the box, so if you think you're just updating components you fetched for yourself, you'll accidentally install this one, too. And they're going to ask you every boot until you disable the check - and then they'll just re-enable the prompt next time they have a patched version to release.

What next, "we suggest you update to Bootcamp and Mac OS X, please wait while we install, and don't mind the reboots"?

Seriously, Apple, this just makes you look seriously unethical. You can't get people to install Safari legitimately, by enticing them to voluntarily download and install it, so you have to sneak it in by implying it's an update to QuickTime. What does that say about Safari? You can't even give it away? You have to foist it on the unwilling?

Grow up.

I suggest we call this behaviour Retro-Bundling.

Bundling, of course, is when you buy a piece of software, or download it for free, and along with it comes Firefox or the Google Toolbar. Irritating, especially if you don't want them, because half of your time in getting the software down was taken up in downloading something that you're going to say "no" to. But at least you only have to say no that one time - or when you download the next version.

Retro-Bundling, then, would be when, after you already have the software of your choice installed, its manufacturer decides that they'd like to have bundled something else onto your system, so they try to slip it in the back door without you noticing.

I am glad to say, to judge from comments at other blogs, that I'm not the only one that thinks this is utterly reprehensible behaviour. Perhaps this is the way things are done in the Apple world - you just sit happily back as your vendor dumps more and more product into your lap.

Consider this - how would you have reacted, if next time Office for Mac was checking for updates, it came back and offered to update Word, Excel Internet Explorer and Silverlight? Even though you didn't have those last two on your system. Oh, and they were selected automatically, and the default button press would install them all.

Update: Someone mentioned to me that Microsoft does indeed offer Silverlight on Windows Update to Windows users even if you don't have Silverlight installed already. That sucks, too. It's not quite as heavy an application as Safari and iTunes, but it's still wrong to offer "updates" that consist of an application you don't have. Actions like this will cause people to stop accepting updates as a regular part of their computing schedule - and that can't help the health of their computers.

CS-RCS Pro on Vista

Alun Jones — Tue, 26 Feb 2008 19:55:06 GMT

I've been trying back and forth to get CS-RCS Pro, a version control suite, to work on Windows Vista.

I like CS-RCS Pro for a number of reasons:

Files stored in CS-RCS Pro are kept in a simple format, open and well-documented. As a result, if I ever have to move away from CS-RCS Pro (say, for instance, if they go out of business, or stop supporting it), I stand a good chance of reconstructing my versioning information completely in whatever product I move to, if only by re-creating files at each epoch and then checking them in to the new tool.
CS-RCS Pro integrates with Visual Studio. I can check files in and out while I'm editing them.
CS-RCS Pro integrates with Explorer, as a Shell Extension, so that you can right-click on source files, and check them in from there.
Of course, most important is that for single users, it's free.

But that last point is the cause of a big problem.

Here's the sequence I have to deal with:

I have the single-user version of CS-RCS Pro.
I use best practices for development of secure applications, particularly as regards running my software and my development tools as a restricted user unless it is strictly necessary to become an admin to test admin-level features, or to install / uninstall software or services, or to debug code that is running a different user context from my own.
CS-RCS Pro insists that the user who installs it is also the user who runs it.
CS-RCS Pro must be installed by an administrator.

I had originally intended to follow the appropriate installation practice for an enterprise application - that it should be installed by a recognised administrator, and then any post-install setup to customise for the end-user would be carried out by that end-user for themselves.

This didn't work, as CS-RCS Pro configured the version control tree to be used by the administrative user, making it impossible for my restricted user to access the files.

I tried simply editing the ownerships and ACLs - that didn't work - and then to additionally edit the configuration files, where it mentioned the name of my administrative user. That worked for a short while, but I noticed that every time I used MSTSC - Remote Console - also known as the Terminal Services Client - to access the system, the shell extension that CS-RCS Pro installs took up 100% CPU, and required that I restart Explorer. There are still a few applications that don't work well when you kill Explorer from underneath them, and so this was somewhat of an untenable position.

Besides, this was an awful lot of effort to go through in order to get version control going.

Finally, it hit me how I should do this properly. It's not clean and it's not clever, and ComponentSoftware, the folks behind CS-RCS Pro, should consider how to change their installer to avoid this issue.

The simple five-step process is as follows - let's say Wayne, an administrator, wants to install the software for Sharon, a restricted user:

Wayne adds Sharon to the Local Administrators group on the machine to which Wayne will be installing CS-RCS Pro.
Wayne logs on as Sharon (*)
Wayne installs the application.
Wayne logs off Sharon's account.
Wayne removes Sharon from the Local Administrators group.

(*) Note that asterisk - that's the troubling part. Actually, step 1 is troubling too, but only because Sharon may have other processes trying to log in with elevated rights, should they ever be granted.

Step 2 requires either that Wayne allows his user, restricted though she is meant to be, to log on as an administrator - what if she quickly runs some tool that you don't want her to run?

Okay, so you drag her away from the console immediately after she types her password - but what if she's got startup items to add an administrative user on her behalf, or simply to stay in memory (as a service, say) and run with those enhanced privileges, to allow exploit later?

Alright, so what's the safest way? The only good way I can think of is this:

Wayne resets Sharon's password.
Wayne adds Sharon's account to Local Administrators. Note that Sharon can't log on at this point.
From a command prompt in Wayne's restricted user account, Wayne uses the runas command to execute the installation script in Sharon's new administrative context. Runas reduces, and possibly eliminates, the chance that this administrative context will have the ability to run Sharon's own code (unless the installation script does so).
Wayne removes Sharon from the Local Administrators account.
Wayne sets Sharon's account to force a password change after the next logon.
Wayne tells Sharon her new password.
If this is not a domain environment, Sharon must change her password back to what it used to be, so that it is possible for her to access her protected data.

Some of you are probably reading this and wondering why I bother - after all, in many environments, developers insist on running as administrator all the time, because their development tools don't support anything else.

Well, it's time your developers - and their tools - grew up. Yes, I can quote, just as any other developer can, a number of cases where administrative access is required - although many developers actually get this wrong. You can run Visual Studio 2005 as a non-administrator. You can debug your own code running in your own logon session as a non-administrator.

Developers are very often the only people to run some sections of the code that they build, until it reaches the hands of the users. As such, developers need to spend as much time as possible, when they run their code, working in the same kind of user context as their users will have.

In general, developers should follow the same principle as other administrators - their day-to-day tasks (e-mail, web browsing, and yes, development) should be done in restricted user accounts; administrative user accounts should be available, but their use should be restricted to those operations which absolutely require administrative access, and those operations should be reviewed often enough to ensure that they need administrative access. Tools and environments grow and change, and a tool which yesterday required administrative access may run tomorrow without. LogonUser, for instance, used to require complete system access - today it can be called by any user.

MacBook Air debuts; iTunes Pesters Me Again

Alun Jones — Sun, 20 Jan 2008 02:09:24 GMT

The big news from Apple this week was that they have a flatter laptop than anyone else (except Intel, who have a "Lorado" concept model that is much cooler, is demonstrated with Vista, and comes with an optional sleeve that has a Sideshow display). Conveniently for those road warriors that take to the air, the MacBook Air resolves the issue of how to carry your spare battery and comply with recent FAA rules - by having no user-replaceable battery. Special.

It also boosts the market for DVD decoders and CD rippers, by not having an on-board optical drive (there have been thinner laptops that had an optical drive). Good luck playing any game that requires you to "insert the original disk".

Okay, enough bashing of the MacBook Air - it looks small, light and may be very useful for people who value that above all else.

As for my usual monthly complaint with Apple, I thought I had it beaten last month, after a visitor commented that I could simply tell Apple Software Update to "Ignore Selected Updates", to make sure that when a new version of QuickTime comes out, I'm not bugged to install "iTunes + QuickTime" as well as Quicklime itself.

Oh dear, no such luck.

Apparently, what I told Apple Software Update to ignore was not so much "iTunes + QuickTime", but "iTunes + QuickTime 7.5".

I feel like the character in Monty Python who is repeatedly offered dishes containing various items - and Spam. "But I don't like Spam!"

Rather than enticing me, seducing me, or deceiving me, into running iTunes, all that this behaviour has done is to make me abandon all hope, and simply dump QuickTimes and Apple Software Update as simply a bad job.

Next time there's a movie file in QuickTime that I want to watch, I'll contact whoever hosts it and let them know that I just can't accept Apple's absurd patching methodology, and that if they want me to view their content, they'll just have to convert it to something more standard, like MPEG, that has viewers made by someone - pretty much anyone - other than Apple.

Removing Apple Mobile Device Support

Alun Jones — Tue, 18 Dec 2007 01:38:00 GMT

As mentioned before, I'm not a fan of Appple's, particularly because they tend to impose crap on me that I'm not interested in having.

I've been trying to figure out how to remove iTunes, iPod and Aple Mobile Device Support on and off now for the past month, since it was accidentally installed while trying to update to the latest safe version of QuickTime (which has since been patched again, and is therefore no longer the safe version of QuickTime - another reason why I wanted to revert to my original state before this month's update). I am, of course, using Windows Vista, so there's a good chance that Apple's technology hasn't caught up with Vista.

iTunes and the iPod service seemed to go easily enough - Control Panel -> Programs and Features -> Select iTunes, and then press Uninstall.

I'm left, though, with the "Apple Mobile Device Support", which is particularly insulting because I don't have any Apple Mobile Devices, so there's no reason why it should have ever installed in the first place.

Every time I tried to Uninstall, it would prompt me for elevation, and then apparently uninstall, although there's no final dialog to say "Uninstalled - OK".

But the icon and program name are still there in "Programs and Features", and the service itself is still present.

I eventually spend a while watching the uninstall procedure, boring as it is to watch a progress bar that reads "11 seconds remaining" then "14 seconds remaining", etc, as progress bars tend to do.

But then the progress bar does something magical - it goes backwards, and when it reaches zero, the uninstall program just quits.

Surprisingly enough, this is good news. It means that rather than the uninstall procedure hitting a random crash and bombing out, it detected an error.

Running EventVwr, I see:

Windows Installer removed the product. Product Name: Apple Mobile Device Support. Product Version: 1.1.2.23. Product Language: 1033. Removal success or error status: 1603.

Well, no, Windows Installer didn't remove the product. To find out what error 1603 means, we can quickly run "net helpmsg 1603", to find that it means:

C:\Program Files>net helpmsg 1603
Fatal error during installation.

Great. That, we already knew. So, it's a generic failure message.

Searching around, I find first, that error 1603 occurs in so many other applications, and with so many causes, that it's not going to help me much.

Apple's support is no help - searching for "uninstall apple mobile device support" gives nothing helpful:

which is surprising since there is this page:

Removing iTunes, QuickTime, and other software components for Windows XP

Removing iTunes, QuickTime, and other software components for Windows Vista

I'm not sure I trust anything that tells me "run the uninstall program, and then go ahead and delete some of the directories it left around, but be careful not to delete other directories it left" - I'm paraphrasing here.

I'll save Windows Installer logging for later, because quite by chance, I found out how to remove Apple Mobile Device Support from Windows Vista.

Instead of clicking "Uninstall", click "Change". You're given the option to "Repair" or "Remove".

Click "Remove".

As counter-intuitive as it sounds, this appears to take you through a completely different uninstall procedure, which actually results in the removal of the Apple Mobile Device Support.

After all of this, of course, Apple's Software Update once again pops up and begs me to update to QuickTime and iTunes + QuickTime.

And when iTunes + QuickTime is apparently a couple of versions ahead of QuickTime, and is selected by default, how many users are going to find themselves deceived into installing an unwanted iTunes?

Come on, Apple, an update takes existing software and advances it. Adding extra, unwanted, software isn't part of the update. Stop offering iTunes + QuickTime as an "update" to QuickTime. Even if you think iTunes is a good thing, it's not an "update", it's an "upgrade", and should not be selected by default, nor should it be described as an update.

Microsoft Support Switches to Live Search

Alun Jones — Sat, 15 Dec 2007 20:25:18 GMT

In the spirit of the famous review of Spinal Tap's album "Shark Sandwich", I was tempted to post a two-word review,the first word of which is "Advanced".

My three-word review, then - "Worst. Search. Ever".

But, just in case you didn't get the hint, here is the explanation:

How on earth is this an "Advanced Search"? Because I can tell it I want to limit my search to the KB, all of Microsoft, or all of the Internet? If those are the only options I care to use, I can go to Google.

I come to the support page - particularly the Advanced Search - so that I can select what product I'm looking for an answer on, and then type my search query. Sometimes, when I'm searching for an article I know I've seen before, I'll search just in the title. Here's how the site looked in June 2007, according to the Wayback Machine:

Microsoft, I know you want us all to use http://search.live.com, which seems to be a good search engine (though harder to type than google.com), but by associating the name with a substandard search on your support web site, I think you will have achieved the opposite effect.

I'd rather associate search.live.com with the fantastic http://maps.live.com - with 3d that really is 3d - or with Windows Live Writer, which provides me with an excellent blogging environment - or with Windows Live Messenger, which is useful if you can ignore the adverts.

In fact, there are many features of search.live.com to love - the image search, which presents an infinitely-scrollable plane of picture results, or the video search, with previews of the videos.

But don't turn the utility of a support-friendly search into the futility of a flat search. When it comes down to it, and perhaps being a little hostile, I can Google Microsoft's Knowledge Base just as easily from Google as I can from http://support.microsoft.com.

A specialised search location requires the use of specialised knowledge to make the search more ... special. If you use a special tool or special interface to do that, you aren't implying that your general search tool is bad.

I didn't want iTunes - now I've got iPod, too?

Alun Jones — Wed, 28 Nov 2007 02:41:32 GMT

So, in my last post "Can the EU get me QuickTime N?", I noted that my installation of QuickTime (because I had a .MOV file I want to see) led to Apple Software Update offering me "iTunes + QuickTime 7.5", despite my removing iTunes every time I find it creeping its way onto my computer.

Now I find that along with that iTunes update, came something that most definitely was not advertised:

My first thought is that if they are going to dump an iPod Service on me, the least they can do is give me a free iPod to use it with.

My second thought is ... that really crosses the line.

At least with my inadvertent installation of iTunes, some careful reading, and not guessing, would have prevented me from installing it.

But at no point did I ever agree to installing an iPod Service. I don't have an iPod, so I don't need an iPod Service.

Oh, excuse me, two services - there's also an "Apple Mobile Device" service. And that service requires TCP to be present before it starts. The iPod service requires RPC to be present before it'll start. So, both of them engage in some form of network communication.

Maybe we should take a look at Microsoft's Windows Defender, and its standards for what constitutes spyware.

Deceptive behaviors. Runs processes or programs on the user's computer without notifying the user and getting the user's consent. Prevents users from controlling the actions taken by the program while it runs on the computer. Prevents users from uninstalling or removing the program.
Privacy. Collects, uses, or communicates the user's personal information and behaviors (such as Web browsing habits) without explicit consent.
Security. Attempts to circumvent or disable the security features on the user’s computer, or otherwise compromises the computer's security.
Performance. Undermines performance, reliability, and quality of the user's computing experience with slow computer speed, reduced productivity, or corruption of the operating system.
Industry and consumer opinion. Considers the input from software industry and individual users as a key factor to help identify new behaviors and programs that might present risks to the user's computing experience.

If you want, read the page linked to, it's got more detail on what criteria Microsoft looks for in identifying spyware - I think you'll find that an objective reading matches the iPod Service's behaviour up with several of the more detailed criteria.

For this blog, though, lets take the overview headings one by one:

Deceptive behaviours. Yes. Absolutely, it's running a process right now that it didn't tell me was going to be added. I had no reason to expect that there's going to be an iPod Service installed.
Privacy. No idea - I'm not leaving it there long enough to collect, use, or communicate anything back to Apple.
Security. Yes - adding a service running as LocalSystem adds to an attack surface that I try to keep low. Besides, "LocalSystem"? Why? Windows Mobile uses Local Service, far less powerful an account.
Performance. One more service that's running permanently, that I'll never use - yes, that's going to affect performance, and reliability.
Industry and consumer opinion. Well, this consumer says yes, it's a bad thing. Maybe not because Apple is trying to write spyware on purpose, but because they ought to know better than to write spyware by accident.

Of course, Microsoft is hardly likely to use this as a reason for Windows Defender to stamp out the iPod Service - they're too afraid of being sued for the federal crime of 'messing with Apple'.

And I certainly haven't found any reason to believe that Apple's iPod Service is calling home or acting like spyware - so just let's use a term from Sandi's vocabulary, "foistware". [But that may be just because I haven't really tried looking.]

Can the EU get me QuickTime N?

Alun Jones — Wed, 28 Nov 2007 01:52:51 GMT

So, a long time ago, in a continent not so far away, the European Union required Microsoft to ship a version of Windows without Media Player, called Windows XP N.

Now, here's a follow-up to my previous articles:

Once again, I find Apple's Software Updater offering me "iTunes + QuickTime 7.5", in response to a security flaw in QuickTime.

"Strange," I think, "I can only see QuickTime 7.3 for download at the Apple download site - not 7.5. Clearly, this is an urgent update that they haven't had a chance to put up on the web site. I'd better install it quickly."

Uh, no.

As you'll tell from my previous columns, I don't want iTunes.

Let me say that again, clearly:

I don't want iTunes.

Ever.

[Unless I change my mind, and if that ever happens, then I will hunt iTunes down for myself.]

So, Steve Jobs, or any Apple fans, how can I install QuickTime so that it's devoid of iTunes, remains devoid of iTunes, doesn't keep bugging me to install iTunes, never offers me an advert for iTunes, and doesn't cause Apple Software Update to go searching for and offering iTunes?

...

FX: Crickets chirping.

I want QuickTime N - a version of QuickTime that I will have to assert strong personal preferences before it will re-associate itself in any way whatsoever with a program that I don't want to put on my machine. [That's iTunes, by the way.]

[Actually, I don't want QuickTime at all - I want to play .MOV files very very rarely. There's a big difference.]

And while we're there, let's have a registry setting from each of the companies involved that says "I don't ever want to be asked to install the Google Toolbar, the Yahoo Toolbar, the Ask.Com Toolbar, unless I go out deliberately, and manually download and install the affected application on its own in the absence of any other software."

Please, all you installation programmers out there, stop bugging me.

Really, please stop it!

If I wanted your free software, I'd go get your free software. Feel free to tell me about it, but don't offer it up as a default installation with something else.

And for those of you programmers who are looking to include some random piece of junk - sorry, some excellent tool that you adore beyond all else (and whose owners have paid you to carry it) - don't make me think while I'm installing your program, if for no other reason than that every time you give me another reason to stop installing, you increase the chance that I'll stop and go elsewhere.