Tales from the Crypto : What my wife knows

Why changing passwords should be done regularly

Alun Jones — Tue, 03 Nov 2009 04:59:19 GMT

A little birdie sent me a copy of today’s SANS ISC diary entry. That’s a good thing, because I’m at home sick with alleged piggy flu, and I’m not able to keep up with a whole lot.

The diary entry argues that regular changes of passwords are often done for no other reason than “because we’ve always done it that way”.

Apparently, people responsible for security policy have “read somewhere” that you’re supposed to change passwords every ninety days, and having no other basis on which to proceed, that’s the policy carved in stone.

When asked why this policy is the way it is, the usual response is “good security practice” – and in such environments it’s difficult to give a good response to someone who pushes back, arguing that changing passwords in their application is ‘difficult’ or, more often, ‘expensive’. This is, after all, business, and if one side pleads “expense”, while the other side pleads “good thing to do”, the latter side will lose.

So, why is it best practice?

One reason is that you have to recognise that for all that we tell users not to share their passwords, not to use the same password on multiple sites (aka “share their passwords”), etc, very often users will do exactly that. So, every ninety days, you change your password and you cut off everyone with whom you previously shared your password (to an extent).

Another reason is to allow changes in password policy to propagate out to new passwords. If you suddenly realise that passwords can be easily hacked if they are only six characters, you change the password policy to require punctuation as well, and then you realise that because no one has to change their password, the new policy will never be applied.

Those are the common arguments for regular password changes, and there are a few others, but there’s one I rarely hear being made.

What about when you do get an exposure?

In my professional career, I have seen, or heard of, a number of cases of exposure of password information. Sometimes it’s as simple as a departing employee who knows far too much information and may not be trusted, or as mind-boggling as a team sharing a list of important passwords, and one of the team members losing the list. Other times it’s more complex.

Each time, the response from security is the same – if the existing passwords are in danger of being used because of such exposure, then those passwords need to be changed.

Most times, the response from the business is the same – that the passwords haven’t been changed in so long, and they’re spread through so many different applications, that they have no idea what will be affected if they change the password.

Once you hit that scenario, it can be months before you get the password changed. Yes, months. And all during that time, the account may be compromised.

How do you prevent this?

Think of your disaster recovery drills – when there’s a process that needs to be followed quickly and correctly in an emergency situation, you achieve that by meticulous planning and regular exercise. You create the process and test it regularly, updating the process as you find there’s a need.

If you don’t change passwords on these high-value accounts once every 90 days (or so), how do you know that you’ll be able to change those passwords after an exposure or compromise? How will you guarantee that your password change procedures are current, without testing them? How will you enforce changes being documented if you don’t check the documentation against reality once in a while?

Windows 7 – what it’s missing

Alun Jones — Fri, 23 Oct 2009 04:16:26 GMT

Unless you’ve been living under a rock, you’ll be aware that today was the release of Microsoft’s latest operating system version, Windows 7.

So, everyone else has their own ideas of what’s missing in Windows 7, here’s my list, and it’s not the same petty focus that everyone else seems to have. Mine is based on what I want, rather than what’s remotely close to being reasonably achievable.

Media Center devices to provide support for DirecTV.
Trimmable transparent screen overlays supporting multi-touch input.
IPv6 support from my home ISP.
A web browser that opens quickly enough that I don’t forget what I was about to browse to.
A tool to answer “why is the system so slow right now?” – especially on those occasions when the CPU is not being over-taxed.
A free Zune HD. (Why not, since I’m dreaming here.)
Simple facilities to allow electronic commerce to operate on ‘zero knowledge’ principles, so that I would share my credit card account number only with my credit card provider, rather than with every merchant I might do business with. (Maybe Infocard or something like it could come close to fulfilling this wish)
An “Expert” mode, where menus are visible, files and file extensions are not hidden in Explorer. (For that matter, file extensions should not be hidden in Explorer. Ever.)
MSN – excuse me – Windows Live Messenger that works in a somewhat rational way, back in the system tray, rather than as a minimised icon.

So, what are the things in your twisted imaginings that would turn Windows 7 from this kind of Seven:

into this kind?

[Note: Having said all of this, it should be clear by now that I think Windows Seven is well worth having. But I still want more!]

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.

Zune HD – but not mine

Alun Jones — Wed, 16 Sep 2009 04:36:00 GMT

A friend of mine ordered a Platinum Zune HD recently (that’s the 32GB model), and because he was unable to receive the shipment, asked for me to open it for him and check on its functionality to make sure he hadn’t been shipped a lemon.

Since I’ve previously commented on the Zune 30 that my wife bought for my birthday, I thought I’d have a quick look and see what I like about it.

The demonstration video is stunning, and shows off the display impressively. The display is wonderfully bright, and fulfils every bit of the promise of OLED technology. Light-weight, thin, amazingly bright and detailed.

Installing the new Zune software from http://www.zune.net/setup went smoothly, although when the player was plugged in, the Zune software immediately insisted on a Player update. The Zune needs to be updated from 4.0 to 4.1 already.

This may come as a surprise, but really it’s not too shocking. There’s a considerable gap between preparing a bunch of hardware for simultaneous shipping and the actual delivery, during which time there may be some interesting bugs discovered. Possibly this time, the bug is that the charge indicator doesn’t light in version 4.0, but does light up in version 4.1. At least, that’s a change I noticed.

So, have any of my previous complaints been addressed? Given the timing of my last post, close to the end of the Zune HD’s development, I doubt that Microsoft had a chance to fix the problems I noted, and I seem to be correct about that.

You can still put MP3 files into your Podcast folder and give them a genre of “Podcast” in order to make them work like Podcasts (i.e. remembering their position while you go do other things), but the images tied into the MP3 files are still not displayed along with those podcasted MP3s. And they still don't play ordered by track number, preferring instead to use some bizarre combination of date and textual sort, with some apparent randomness thrown in.

It appears so far that all of the other issues I’ve encountered are still there, so I’m still waiting for someone at Microsoft to address those and deliver a Zune (updated firmware, software, or hardware) that is absolutely perfect. If they could make it cheaper, too, it would be easier to justify a purchase.

But man, I love that bright display on the new Zune HD. I just wish I didn’t have to part with this one so soon. I guess I’d better save my Amazon gift cards…

How FTP Data Connections Work Part 2 (OR: Fun With Port 20)

Alun Jones — Tue, 14 Jul 2009 06:48:26 GMT

As we mentioned in the 1st part of this series, FTP is a more complex protocol than many, using one control connection and one data connection.

A recap of the first post…

In typical Stream Mode operation, a new data connection is opened and closed for each data transfer, whether that’s an upload, a download, or a directory listing. To avoid confusion between different data connections, and as a recognition of the fact that networks may have old packets shuttling around for some time, these connections need to be distinguishable from one another.

In the previous article, we noted that two network sockets are distinguished by the five elements of “Local Address”, “Local Port”, “Protocol”, “Remote Address”, and “Remote Port”. For a data connection associated with any particular request, the local and remote addresses are fixed, as the addresses of the client and server. The protocol is TCP, and only the two ports are variable.

For a PASV, or passive data connection, the client-side port is chosen randomly by the client, and the server-side port is similarly chosen randomly by the server. The client connects to the server.

For a PORT, or active data connection, the client-side port is chosen randomly by the client, and the server-side port is set to port 20. The server connects to the client.

All of these work through firewalls and NAT routers, because firewalls and NAT routers contain an Application Layer Gateway (ALG) that watches for PORT and PASV commands, and modifies the control (in the case of a NAT) and/or uses the values provided to open up a firewall hole.

Isn’t there a totally predictable data connection?

For the default data connection (what happens if no PORT or PASV command is sent before the first data transfer command), the client-side port is predictable (it’s the same as the source port the client used when connecting the control channel), and the server-side port is 20. Again, the server connects to the client.

Because firewalls and NATs open up a ‘reverse’ hole for TCP sockets, the default data port works with firewalls and NATs that aren’t running an ALG, or whose ALG cannot scan for PORT and PASV commands.

Why would an ALG stop scanning for PORT and PASV commands?

There are a couple of reasons – the first is that it doesn’t know that the service connected to is running the FTP protocol. This is common if the server is running on a port other than the usual port 21.

The second reason is that the FTP control connection doesn’t look like it contains FTP commands – usually because the connection is encrypted. This can happen because you’re tunneling the FTP control connection through an encrypted tunnel such as SSH (don’t laugh – it does happen!), or hopefully it’s because you’re running FTP over SSL, so that the control and data connections can be encrypted, and you can authenticate the identity of the FTP server.

So how do you get FTP over SSL to work through a firewall?

In the words of Deep Thought: “Hmm… tricky”.

There are a couple of classic solutions:

Allow PASV data connections, select a wide range of ports, and open that range for incoming traffic from all external addresses in your firewall configuration; hope that your FTP server can be configured to use only that range of ports (WFTPD Pro can), and that it has protections against traffic stealing attacks (again, WFTPD Pro has). Still, this option seems really risky.
Block all PASV connections, and make the clients responsible for opening up holes in their firewalls. If you’re convinced the risk is too great to do this on your server, how does it look to convince your users that they should accept that risk?
After you’ve authenticated the server and provided your username and password in the encrypted control connection, issue the “CCC” (Clear Control Channel) command, to switch the control connection back into clear-text. I dislike this as a solution, because it requires the ALG pay attention to a lot of SSL traffic in the hope that there might be clear-text coming up, and because you may want the control channel to remain encrypted.

Awright, clever clogs, you solve the problem.

The astute reader can probably see where I’m going with this.

The default data port is predictable – if the client connects from port U to port L at the server (L is usually 21), then the default data port will be opened from port L-1 at the server to port U at the client.

The default data port doesn’t need the firewall to do anything other than allow reverse connections back along the port that initiated the connection. You don’t need to open huge ranges at the server’s firewall (in fact you should be able to simply open port 21 inbound to your server).

The default data port is required to be supported by FTP servers going back a long way- at least a couple of decades. Yes, really, that long.

If it’s that simple, why isn’t everyone doing it?

Good point, that, and a great sentence to use whenever you wish to halt innovation in its tracks.

Okay, it’s obvious that there are some drawbacks:

In stream mode, the data transfer is ended by closing the stream. This means that you have to open a new control connection. Not good, given the number of round-trips you need for a logon, and the work needed to start an SSL connection.
Most FTP clients view the default data connection as, at best, a fail-over in case the PORT or PASV commands fail to work. Obviously, that means it’s not likely to be a well-tested or favoured solution on these clients.

Even with those drawbacks, there are still further solutions to apply – the first being to use Block-mode instead of Stream-mode. In Stream-mode, each data transfer requires opening and closing the data connection; in Block-mode, which is a little like HTTP’s chunked mode, blocks of data are sent, and followed by an “EOF” marker (End of File), so that the data connection doesn’t need to be closed. If you can convince your FTP client to request Block-mode with the default data connection, and your FTP server supports it (WFTPD Pro has done so for several years), you can achieve FTP over SSL through NATs and firewalls simply by opening port 21.

For the second problem, it’s worth noting that many FTP client authors implemented default data connections out of a sense of robustness, so default data connections will often work if you can convince the PORT and PASV commands to fail – by, for instance, putting restrictive firewalls or NATs in the way, or perhaps by preventing the FTP server from accepting PORT or PASV commands in some way.

Clearly, since Microsoft’s IIS 7.5 downloadable FTP Server supports FTPS in block mode with the default data port, there has been some consideration given to my whispers to them that this could solve the FTP over SSL through firewall problem.

Other than my own WFTPD Explorer, I am not aware of any particular clients that support the explicit use of FTP over SSL with Block-mode on the default data connection – I’d love to hear of your experiments with this mode of operation, to see if it works as well for you as it does for me.

Nice support from Lenovo

Alun Jones — Sun, 12 Jul 2009 19:11:01 GMT

I’ve been wanting to post this comment for some time, but never seemed to get around to it.

I’ve been through a number of different laptops over the last decade or so – Compaq, Dell, Gateway, and Toshiba – and each time, I’ve found that they just don’t seem to last. I can’t point to anything in particular – it’s never the same thing twice, but for one reason or another, I don’t get more than a couple of years’ life out of a laptop. Sometimes it’s physical failure – the screen breaks, the drive fails, the battery stops holding a charge – and sometimes it’s simply that the machine is too slow and impossible to upgrade to support me as new software is needed.

Unless I buy a ThinkPad.

It’s not that the ThinkPad doesn’t have its problems – it’s more that IBM support always made things right. When the CD-R drive on my first ThinkPad started failing, I called them up, and they quickly sent me a replacement (taking, as usual, my credit card number as guarantee in case I didn’t send them the drive back). The replacement turned out to be a DVD-R drive, so I was ahead on that deal – particularly since the failure happened right at the end of the warranty period.

So my more recent ThinkPad concerned me, coming as it did with a Lenovo sticker instead of IBM.

As usual, problems with the laptop happened once in a while. About six months in, the laptop battery stopped retaining its charge. I’m used to companies telling me that the battery is only warranted for 90 days, and that when batteries stop holding their charge, it’s because of my usage patterns (whatever that means – isn’t a battery supposed to be used when you’re on the bus or train, or in a meeting?)

Not these guys, no, they sent me a replacement battery (after the ritual exchange of credit card numbers).

One persistent problem stayed with me from the first few months of the purchase of the laptop – the sound stuttered. Now, I should note here what I mean by “stuttered”, because I gather others have sound stuttering that isn’t the same problem as mine.

Imagine, if you will, that the speakers can handle sounds only “so” loud. Pass any sounds louder than that to them, and the sound ceases until the sound is back to a good volume. So, the timing of the sound is unaffected, it’s just as if someone’s repeatedly hammering the ‘mute’ button. Not a problem if everything’s normalised to below 70%, say, but then that’s difficult to listen to because it’s so quiet.

That’s the problem I had – the other sort of problem appears to be where the processing of the sound signal is held up, so the timing of the sound is affected, as if someone is hammering a ‘pause’ button repeatedly on and off.

I called Lenovo a couple of times about this, and assumed it was simply not going to be fixed, as they kept suggesting new drivers, or that I take it to a service centre where they would decide if it could be fixed there or had to be sent away. I wasn’t keen on the service centres they were suggesting.

Finally I reached the end of my warranty, and also the end of my patience with the problem – I was playing more and more stuff from BBC Radio (see a theme here?), and they were coming through normalised properly, rather than dead quiet. So, I either had to re-normalise everything myself, or get the problem fixed.

I called Lenovo, spoke to a nice man in North Carolina, and was told they’d have to look at the system. I’d have to send it in.

I hate being without my laptop – all the more so because I had to send in my hard drive as well. So, it’s make-a-backup time, plus delete-all-the-secrets. A box arrived, with paid shipping, I stuck the laptop in the box, and sent it back. Over Thanksgiving, so that “5 business days” became naturally closer to two weeks, and because it eventually took a while to fix the problem, closer to three weeks.

When I received the system back, I noticed a few things:

The sound problem had been fixed.
The mainboard had been replaced.
These repairs had all been done for free despite the fact that I was a couple of weeks past warranty expiration when I first called.

You’ll often hear people bad-mouthing non-US companies for having poor technical support that doesn’t speak English and can’t often help – and though this may be true for Lenovo’s online support ‘chat’ (where you type into a browser window), it’s not true for their phone support, and I really can’t argue with the quality of the warranty work they’ve done for me (and how comfortable they were stretching the warranty in the instance that I had been complaining for a while before the warranty expired).

Perhaps it’s a little sad that I have to post a glowing review like this of support that matches roughly what I would expect. But I think Lenovo deserves a pat on the back for this support, and I can only apologise that it has taken me so long to get around to doing so.

I will likely be buying another Lenovo ThinkPad when I finally need to dispose of this one.

How FTP Data Connections Work Part 1 (OR: Don’t Open Port 20 in your Firewall!)

Alun Jones — Thu, 09 Jul 2009 06:18:42 GMT

This will be the first of a couple of articles on FTP, as I’ve been asked to post this information in an easy-to-read format in a public place where it can be referred to. I think my expertise in developing and supporting WFTPD and WFTPD Pro allow me to be reliable on this topic. Oh, that and the fact that I’ve contributed to a number of RFCs on the subject.

Enough TCP to be dangerous

First, a quick refresher on TCP – every TCP connection can be thought of as being associated with a “socket” at each device along the way – from one computer, through routers, to the other computer. The socket is identified by five individual items – the local IP address, the local port, the remote IP address, the remote port, and the protocol (in this case, the protocol is TCP).

Firewalls are essentially a special kind of router, with rules not only for how to forward data, but also rules on connection requests to drop or allow. Once a connection request is allowed, the entire flow of traffic associated with that connection request is allowed, also – any traffic flow not associated with a previously allowed connection request is discarded.

When you set up a firewall to allow access to a server, you have to consider the first segment – the “SYN”, or connection request from the TCP client to the TCP server. The rule can refer to any data that would identify the socket to be created, such as “allow any connection request where the source IP address is 10.1.1.something, and the destination port is 54321”.

Typically, an external-facing firewall will allow all outbound connections, and have rules only for inbound connections. As a result, firewall administrators are used to saying things like “to enable access to the web server, simply open port 80”, whereas what they truly mean is to add a rule that applies to incoming TCP connection requests whose source address and source port could be anything, but whose destination port is 80, and whose destination address is that of the web server.” This is usually written in some short hand, such as “allow tcp 0.0.0.0:0 10.1.2.3:80”, where “0.0.0.0” stands for “any address” and “:0” stands for “any port”.

Firewall rules for FTP

For an FTP server, firewall rules are known to be a little trickier than for most other servers.

Sure, you can set up the rule “allow tcp 0.0.0.0:0 10.1.2.3:21”, because the default port for the control connection of FTP is 21. That only allows the control connection, though.

What other connections are there?

In the default transfer mode of “Stream”, every file transfer gets its own data connection. Of course, it’d be lovely if this data connection was made on port 21 as well, but that’s not the way the protocol was built. Instead, Stream mode data connections are opened either as “Active” or “Passive” connections.

Active and Passive Data Connections

The terms "Active" and "Passive" refer to how the FTP server connects. The choice of connection method is initiated by the client, although the server can choose to refuse whatever the client asked for, at which point the client should fail over to using the other method.

In the Active method, the FTP server connects to the client (the server is the “active” participant, the client just lies back and thinks of England), on a random port chosen by the client. Obviously, that will work if the client's firewall is configured to allow the connection to that port, and doesn't depend on the firewall at the server to do anything but allow connections outbound. The Active method is chosen by the client sending a “PORT” command, containing the IP address and port to which the server should connect.

In the Passive method, the FTP client connects to the server (the server is now the “passive” participant), on a random port chosen by the server. This requires the server's firewall to allow the incoming connection, and depends on the client's firewall only to allow outbound connections. The Passive method is chosen by the client sending a “PASV” command, to which the server responds with a message containing the IP address and port at the server that the client should connect to.

The ALG comes to the rescue!

So in theory, your firewall now needs to know what ports are going to be requested by the PORT and PASV commands. For some situations, this is true, and you need to consider this – we’ll talk about that in part 2. For now, let’s assume everything is “normal”, and talk about how the firewall helps the FTP user or administrator.

If you use port 21 for your FTP server, and the firewall is able to read the control connection, just about every firewall in existence will recognise the PORT and PASV commands, and open up the appropriate holes. This is because those firewalls have an Application Level Gateway, or ALG, which monitors port 21 traffic for FTP commands, and opens up the appropriate holes in the firewall. We’ve discussed the FTP ALG in the Windows Vista firewall before.

So why port 20?

Where does port 20 come in? A rather simplistic view is that administrators read the “Services” file, and see the line that tells them that port 20 is “ftp-data”. They assume that this means that opening port 20 as a destination port on the firewall will allow FTP data connections to flow. By the “elephant repellant” theory, this is proved “true” when their firewalls allow FTP data connections after they open ports 21 and 20. Nobody bothers to check that it also works if they only open port 21, because of the ALG.

OK, so if port 20 isn’t needed, why is it associated with “ftp-data”? For that, you’ll have to remember what I said early on in the article – that every socket has five values associated with it – two addresses, two ports, and a protocol. When the data connection is made from the server to the client (remember, that’s an Active data connection, in response to a PORT command), the source port at the server is port 20. It’s totally that simple, and since nobody makes firewall rules that look at source port values, it’s relatively unimportant. That “ftp-data” in the Services file is simply so that the output from “netstat” has a meaningful service name instead of “:20” as a source port.

Coming up in part 2…

Next time, we’ll expand on this topic, to go into the inability of the ALG to process encrypted FTP control traffic, and the resultant issues and solutions that face encrypted FTP.

Zune – So Nearly Perfect, it Hurts

Alun Jones — Fri, 26 Jun 2009 05:17:39 GMT

For a while now, I’ve been listening to the BBC radio on my MP3 player – even wrote a program to download the audio of various programmes and convert them from RealAudio to MP3 so that I can listen to them on the bus or in my car on the way to and from work. First it was a 512MB Creative Muvo, then a Sandisk Sansa at 2GB.

Then on my birthday, my wife surprised me with a 30GB Zune, just what I wanted. I know there are other more recent models, but I can’t justify the expense of a 120GB model, and the others are too small of a display to be interesting. The Zune HD seems like it would be perfect, but I bet it’ll be too expensive for me to justify.

I really enjoy the Zune, and it solves many of the problems I’ve hated about the Sansa – the biggest being, as I described before, that it requires me to install (and carefully watch for sneaky encroachment) Quicktime, and to run the video/photo converter as an administrator.

So, now that the Zune solves the big problems, I’m starting to become aware of the less horrifying aspects of media player ownership.

Here are the first few little problems (note that this isn’t entirely insurmountable):

Playing a video, or a podcast, kills off the “Now Playing” list.
While you can resume a video, or a podcast, you can’t resume a playlist.
You can’t create a playlist on the device – although you can add Music selections to “Now Playing”, you can’t rename the list, and “Now Playing” gets killed off so easily.
You can’t resume a music item after you’ve paused it and played another. This makes the music folders useless for my radio programmes.
When playing an MP3 file in the music folder, if the MP3 file has a picture (in the ID3 Picture tag), the picture is cropped to fit the display – I’d rather see it shrunk.
Pictures from MP3 files are not displayed individually – one of them is selected as the “Album Art”, and is then displayed for all subsequent MP3s with the same ID3 Album tag. I’d rather see the pictures from the individual MP3s (who knows, maybe they’re important?)
MP3 files from the music folder appear in the “social” under your tag, and the system tries to guess what you’re listening to. Usually appallingly badly. For instance, I play “The Eureka Years”, a radio programme from the BBC, recorded as an MP3 file with appropriate Author and AlbumTitle tags – it lists as the song “Eureka” by “Jim O’Rourke”. I haven’t found where you can correct this, or delete it – goodness only knows how you cope with embarrassing selections made by this guessing algorithm.
You can’t delete a music MP3 file from the device without using the PC. Not much use when I’m on the bus and want to say “yep, I’ve heard that, now delete it”.

Like I said, those are the first few problems I’ve encountered.

Most of these problems seem to be solved by turning my recorded radio programmes into podcasts. Apparently you do this by moving the MP3 files into the podcast directory prior to syncing, and by changing the ID3 Genre tag to “Podcast”. That’s certainly far better, but there are still more problems I’ve encountered with that:

Podcasts without an accompanying XML RSS feed don’t sort right. They should sort primarily by the MP3’s ID3 track #, then by date and time, and finally by name. It appears that the Zune is sorting them primarily by date (ignoring the time!) and then by name, and totally ignoring the track number.
When sorting the tracks in a podcast by name, the sort is alphabetical, with no consideration given to numerical sorting, so my recording of “Journey into Space, World In Peril” plays in the order 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 3, 4, 5, 6, 7, 8, 9. And remember, that’s even with the track numbers present and correct (although maybe it is sorting by track number, but doing it alphabetically rather than numerically!)
I’d rather that podcasts were picked up properly without my having to change the Genre tag – I like my Genre tags to read “Comedy”, or “Drama/SciFi & Fantasy” – and it’d be nice if the podcast tool allowed me to sub-sort the podcasts based on the genre, too!
You can’t “queue up” the podcasts into a “now playing” list, or any other kind of playlist.
Podcasts don’t display the Picture stored in the ID3 tag of the MP3 file – not even as “album art”. The only time images are displayed for podcasts is when the image is referenced in an accompanying XML RSS feed.

So, the next solution set would be to publish an RSS feed.

Unfortunately, this leads to the next failure.

You can’t subscribe to a “file://” based URL – podcast feeds must all start “http://”, which means putting a web server to work even if you’re building a personal podcast feed that exists only between your computer and its associated Zune.

Other problems I’ve experienced are DRM-like, and we all know that I find DRM to be hugely objectionable. Specifically, I can’t transfer any IFC programmes onto my Zune from my Windows Vista Media Center PC, because apparently they’re all tagged as “copyright”. Note that’s my Media Center PC, transferring to my Zune so that I can watch programming recorded from my DirecTV subscription – no theft involved there, I paid for that content, but can not watch it in my chosen locale or medium.

I can only hope that someone at Microsoft reads this post, and reassures me that they’re going to do better with the release of the ZuneHD – and, because I almost certainly can’t afford a ZuneHD (although anyone who knows me will tell you how excited I’ve been about OLEDs for the last year or so), I hope that many of these improvements are back-ported to my lowly Zune 30. I’d be happy to expound on any of these points to get them addressed.

Oh, and if you ask – I would definitely and whole-heartedly recommend getting a Zune. I know that I’m going to be buying one for my wife as soon as I can find it at the right price (I’m hoping for a Woot-off or perhaps a bag of crap containing a Zune]. All the problems I’ve outlined above are really minor and piddly, but it’s these kind of tweaks that turn a merely good product into a great product. I only complain about them because the Zune is so close to perfection for me, it can be fixed with relatively little effort. The Sansa and its software were so far from perfection that it seems likely that the development team totally don’t “get it”. [The Creative Muvo was actually pretty much perfect for what was achievable at the time.]

So, am I missing any obvious tricks for my Zune? Can I get the BBC programmes on it in a better way? [Yes, I know about the BBC podcasts, but there are shows that the BBC just don’t podcast.]

Nobody stopped me, as I put the second laptop into my bag...

Alun Jones — Sat, 08 Nov 2008 22:46:53 GMT

I have two laptops that I carry with me most places I go. This isn't showing off, it's just something I do for a number of reasons. (One laptop is for work, the other is personal)

On a recent trip, I wanted to leave one with my wife as she dropped me off at the airport (flying with more than one laptop just seems silly, all that extra weight) - but she drove off before I could take the superfluous laptop out.

So I proceed to the TSA line, wondering what they're going to say about me packing two laptops.

Nobody noticed. Nobody at all raised an eyebrow at me sliding two laptops into my bag.

That has me somewhat concerned - although it made my trip rather easy.

The implication is that if I am smooth enough of a criminal, I can pick up my laptop and yours, and slide them both into my bag without anyone except you caring – and you’re on the other side of the metal detector from me.

Although it would have slowed my progress through the security line, quite frankly I'd rather someone questioned me about the fact that I was doing something extraordinary in sliding more than the average number of laptops into a bag.

On a number of occasions, my wife (a seasoned traveler) has seen people accidentally swap laptops with her, walk off without their own laptop, or been worryingly detained through the metal detector as their laptops are sitting unprotected and unwatched at the other end of the security scanner.

Recently the TSA produced statistics that showed that many thousands of laptops are abandoned at security lines at the nation's airports - I would be interested to know how many thousands of laptops are not abandoned, but are purloined - accidentally or with criminal intent - by someone other than their rightful owner.

What should the TSA do to prevent theft and/or loss at the security checkpoint? Could the security lines survive if staff insisted on not letting the next person (or their carry-on luggage) proceed until the last person had finished collecting theirs from the output?

Weak point against Vista

Alun Jones — Sun, 12 Oct 2008 00:49:06 GMT

First rule of demonstrative writing – lead off with an undeniable example of the point you’re trying to make.

Case in point – Dan Lyons’ article in NewsWeek on “A Gloomy Vista for Microsoft”, meant to be a piece defining how bad Vista is.

“Last year I was meeting with the CEO of a PC company who offered to give me a demo of his company's gorgeous new top-of- the-line notebook, a machine that cost several thousand dollars and came loaded with Windows Vista, the latest version of Microsoft's operating system. He flipped open the laptop, pressed the power button, and … nothing. We waited. And waited. It was excruciating. He tried control-alt-delete. He tried holding down the power button. Finally he removed the battery and snapped it back into place. The machine started up—slowly—while the CEO sat there fuming.”

Um, yeah, OK, that sounds bad and all, but seriously, if you’re pressing the power button on a turned-off machine and nothing’s happening, that’s hardware. And if you blame hardware faults on the operating system, well, that’s just a CEO trying to ignore the fact that his hardware system and its developers aren’t providing a totally balanced view of their work.

So, let’s carry on reading. What else is a problem with Vista?

“It was sluggish. It had trouble going to sleep and waking up. It wouldn't work with some printers and accessories.”

I didn’t see “sluggish”, but then again, I bought a higher spec machine than my three-year-old laptop in order to run Vista, because it’s a significant update to the OS. Many of its major features expect there to be lots of memory and a fast 3D video card.

The “trouble going to sleep and waking up” part I definitely had some experience with – but then, I have those problems in XP, too: over 1MB in my machine, and XP decided it was going to turn my laptop bag into a pizza oven – to judge from the popularity of my blog post on the issue, I’m far from alone in this. Laptop manufacturers really haven’t had the best of luck in XP or Vista persuading individual devices – let alone the whole system – that it’s nighty-night time, or that it’s time to wake up when you punch the “wake-up” key. Recent updates from Lenovo made my life a little easier, but the machine will still sometimes go to sleep never to wake up again. Really irritating when I’m in the middle of working as the bus arrives at its destination and I have to press the sleep button, praying that the machine will make it through the nap. And I can guarantee to hang the system if I press the sleep button and then close the lid.

And, as for printers and accessories, it’s clear that any number of device drivers weren’t actually used for any significant length of time in the Vista environment, or they’d have shown their incompatible designs. My HP printer, for instance, pops up this ugly dialog whenever I print from Internet Explorer:

Now, I don’t know much about drivers, but I suspect that this could be fixed by signing the driver. My other HP printer continually offers up a new version of its drivers on Windows Update, and then the installation refuses to start, because the printer isn’t plugged in to my machine. Well, of course not, it’s a network printer.

As has been pointed out by numerous other writers, XP had this same sort of flack when it released (although I don’t remember it going on for quite this long), and then as now, most of the problems were to do with software and hardware developers who weren’t paying even limited attention to the statements Microsoft put out as to features that were deprecated (i.e. made obsolete, going away, or otherwise disappearing).

Of course, my wife hates Vista, and at some point I’ll be able to point you to her ideas on the topic, because she has some actually valid arguments as to why Vista sucks. And none of those arguments are represented in Dan Lyons’ Newsweek article.

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.

FTP - Untrustworthy? I Don't Think So!

Alun Jones — Wed, 30 Jul 2008 04:53:15 GMT

Lately, as if writers all draw from the same shrinking paddling-pool of ideas, I've noticed a batch of stories about how unsafe, unsecure and untrustworthy is FTP.

SC Magazine says so.

First it was an article in the print version of SC Magazine, sadly not repeated online, titled "2 Minutes On... FTP integrity challenged", by Jim Carr. I tried to reach Jim by email, but his bounce message tells me he doesn't work for SC Magazine any more.

This article was full of interesting quotes.

"8,700 FTP server credentials were being used to access and infect more than 2,000 legitimate websites in the US". The article goes on to quote Finjan's director of security research who says they were "most likely hijacked by malware" - since most malware can do keystroke logging for passwords, there's not much can be done at the protocol level to protect against this, so this isn't really an indictment of FTP so much as it is an indication of the value and ubiquity of FTP.

Then we get to a solid criticism of FTP: "The problem with FTP is it transfers data, including authorization credentials, in plain text rather than in encrypted form, says Jeff Debrosse, senior research analyst at security vendor ESET". Okay, that's true - but in much the same vein as saying that the same problems all apply to HTTP.

Towards the end of the article, we return to Finjan's assertion that malware can steal credentials for FTP sites - and as I've mentioned before, malware can get pretty much any user secret, so again, that's not a problem that a protocol such as FTP - or SFTP, HTTP, SSH, SCP, etc - can fix. There's a password or a secret key, and once malware is inside the system, it can get those credentials.

Fortunately, the article closes with a quote from Trent Henry, who says "That means FTP is not the real issue as much as it is a server-protection issue."

OK, But a ZDNet blogger says so, too.

Well, yeah, an article in a recent ZDNet blog entry - on storage, not networking or security (rather like getting security advice from Steve Gibson, a hard-drive expert) - rants on about how his web site got hacked into (through WordPress, not FTP), and as a result, he's taken to heart a suggestion not to use FTP.

Such a non-sequitur just leaves me breathless. So here's my take:

FTP Has Been Secure for Years

But some people have just been too busy, or too devoted to other solutions, to take notice.

FTP first gained secure credentials with the addition of support for SASL and SKey. These are mechanisms for authenticating users without passing a password or password-equivalent (and by "password-equivalent", I'm including schemes where the hash is passed as proof that you have the password - an attacker can simply copy the hash instead of the password). These additional authentication methods give FTP the ability to check identity without jeopardising the security of the identified party. [Of course, prior to this, there were IPsec and SOCKS solutions that work outside of the protocol.]

OK, you might say, but that only protects the authentication - what about the data?

FTP under GSSAPI was defined in RFC 2228, which was published in October 1997 (the earliest draft copy I can find is from March 1995), from a draft developed over the preceding couple of years. What's GSSAPI? As far as anyone really needs to know, it's Kerberos.

This inspired the development of FTP over SSL in 1996, which became FTP over TLS, and which finally became RFC 4217. From 1997 to 2003, those of us in the FTPExt Working Group were wondering why the standard wasn't yet an RFC, as draft after draft were submitted with small changes, and then apparently sat on by the RFC editor - during this time, several compatible FTP clients, servers and proxies were produced that compatibly supported FTP over TLS (and/or SSL).

Why so long from draft to publication?

One theory that was raised is that the IETF were trying to get SSH-based protocols such as SFTP out before FTP over TLS (which has become known as "FTPS", for FTP over SSL).

SFTP was abandoned after draft 13, which was made available in July 2006; RFC 4217 was published in October 2005. So it seems a little unlikely that this is the case.

The more likely theory is simply that the RFC Editor was overworked - the former RFC Editor, Jon Postel, died in 1998, and it's likely that it took some time for the new RFC Editor to sort all the competing drafts out, and give them his attention.

What did the FTPExt Working Group do while waiting?

While we were waiting for the RFC, we all built compatible implementations of the FTP over TLS standard.

One or two of us even tried to implement SFTP, but with the draft mutating rapidly, and internal discussion on the SFTP mailing list indicating that no-one yet knew quite what they wanted SFTP to be when it grew up, it was like nailing the proverbial jelly to a tree. Then the SFTP standardisation process ground to a halt, as everyone lost interest. This is why getting SFTP implementations to interoperate is sometimes so frustrating an experience.

FTPS, however - that was solidly defined, and remains a very compatible protocol with few relevant drawbacks. Sadly, even FTP under GSSAPI turned out to have some reliability issues (the data transfer and the control connection, though over different asynchronous channels, share the same encryption context, which means that the receiver must synchronise the two asynchronous channels exactly as the sender did, or face a loss of connection) - but FTP over TLS remains strong and reliable.

So, why does no-one know about FTPS?

Actually, there's lots of people that do - and many clients and servers, proxies and tunnels, exist in real life implementations. Compatibility issues are few, and generally revolve around how strict servers are about observing the niceties of the secure transaction.

Even a ZDNet blogger or two has come across FTPS, and recommends it, although of course he recommends the wrong server.

My recommendation?

WFTPD Pro. Unequivocally. Because I know who wrote it, and I know what went into it. It's all good stuff.

Vistafy Me.

Alun Jones — Fri, 11 Jul 2008 05:07:25 GMT

I have a little time over the next couple of weeks to devote to developing WFTPD a little further.

This is a good thing, as it's way past time that I brought it into Vista's world.

I've been very proud that over the last several years, I have never had to re-write my code in order to make it work on a new version of Windows. Unlike other developers, when a new version of Windows comes along, I can run my software on that new version without changes, and get the same functionality.

The same is not true of developers who like to use undocumented features, because those are generally the features that die in new releases and service packs. After all, since they're undocumented, nobody should be using them, right? No, seriously, you shouldn't be using those undocumented features.

So, WFTPD and WFTPD Pro run in Windows Vista and Windows Server 2008.

But that's not enough. With each new version of Windows, there are better ways of doing things and new features to exploit. With Windows Vista and Windows Server 2008, there are also a few deprecated older behaviours that I can see are holding WFTPD and WFTPD Pro down.

I'm creating a plan to "Vistafy" these programs, so that they'll continue to be relevant and current.

Here's my list of significant changes to make over the next couple of weeks:

Convert the Help file from WinHelp to HTML Help.

WinHelp is not supported in Vista - you can download a WinHelp version, but it's far better to support the one format of Help file that Windows uses. So, I'm converting from WinHelp to HTML Help.

Changing the Control Panel Applet for WFTPD Pro.

CPL files still work in Windows Vista, but they're considered 'old', and there's an ugly user experience when it comes to making them elevate - run as administrator.
There are two or three ways to go here -

one is to create an EXE wrapper that calls the old CPL file. That's fairly cheap, and will probably be the first version.
Another is to write an MMC plugin. That's a fair amount of work, and requires some thought and design. That's going to take more than a couple of weeks.
A third option is to create some form of web-based interface. I don't want to go that way, because I don't want to require my users to install IIS or some other web server.

So, first blush it seems will be to wrap the existing interface, and secondly I'll be investigating what an MMC should look like.

Support for IPv6.

I already have this implemented in a trial version, but have yet to fully wire it up to a user interface that I'm willing to unleash on the world. So that's on the cards for the next release.

Multiple languages

There are two elements to support for multiple languages in FTP:

File names in non-Latin character sets
Text messages in languages other than English

The first, file names in different character sets, will be achieved sooner than the second. If the second ever occurs, it will be because customers are sufficiently interested to ask me specifically to do it.

SSL Client Certificate authentication

SSL Client Certificate Auth has been in place for years - it's a secret feature. The IIS guys warned me off developing it, saying "that's really hard, don't try and do anything with client certs".
I didn't have the heart to tell them I had the feature working already (but without an interface), and that it simply required a little patience.

Install under Local Service and Network Service accounts
Build in Visual Studio 2008, to get maximum protection using new compiler features.

/analyze, Address Space Layout Randomisation, SAL - all designed to catch my occasional mistakes.

As I work on each of these items, I'll be sure to document any interesting behaviours I find along the way. My first article will be on converting your WinHelp-using MFC project to using HTML Help, with minimal changes to your code, and in such a way that you can back-pedal if you have to.

Of course, I also have a couple of side projects - because I've been downloading a lot from BBC 7, I've been writing a program to store the program titles and descriptions with the MP3 files, so that they show up properly on the MP3 player. ID3Edit - an inspired name - allows me to add descriptions to these files.

Another side-project of mine is an EFS tool. I may use some time to work on that.

The difference between liking and hating UAC?

Alun Jones — Wed, 11 Jun 2008 04:17:51 GMT

Totally unscientifically, I have carried out a poll of people who like UAC (okay, a few security geeks like myself), and those who hate UAC - mostly my wife.

Something struck me as both a surprising common factor, and also a rather obvious explanation of why the two opinions are so polarised.

[Note for the pedants - yes, I'm using the term "UAC" here to mean "Elevation" - there are other portions of UAC that I'm not discussing, such as Protected Mode in Internet Explorer, and so on.]

We use UAC for different purposes

UAC-lovers

The UAC-lover seems to have 'got least-privilege religion' at least several years ago, and runs most of the time as a standard, restricted user. Most UAC-lovers do not seem to be "Administering the system all the time" types.

As a result, they use UAC as a means to elevate privilege on those occasions when they need to do something administrative, or when they need to run a program that has not yet been coded to run with least privilege.

When they're doing something administrative, they're comparing the UAC "Over-the-shoulder" (OTS) prompt against the methods that used to be available to them:

Log off and back on - to do this, you have to close out all your applications, saving the documents you were working on, log off, log on as the administrator account, do the admin thing, log off, and log back on as your regular account.
Fast User Switching (FUS) - not available on a domain, and anything but fast. The only advantage it has over logging out and back in is that you maintain your application state in the restricted user - the documents are still open, the programs are still running, etc.
RunAs - this used to be how you elevate in Windows prior to Vista, but now you have to find another tool to do the same job for you, because RunAs won't elevate your session even if you provide it with administrator credentials. [I use Jesper's Elevate Explorer Tools from the Windows Server 2008 Security Resource Kit.]

Given these as alternatives, it's no wonder that UAC and OTS elevation prompts are considered better.

UAC-haters

The UAC-hater is fundamentally disinterested in least-privilege, at least as it applies to users. Least-privilege is an obvious and good programming strategy, a program shouldn't ask for more privileges than it needs, but to this user, that's something that the programmers should care about.

This user wants to be instantly, and automatically, elevated whenever she calls on a feature that would require it. This is how she's used to running the computer, because she's always called on to do administrative tasks - and she's careful and knowledgeable enough to have avoided causing damage through doing so.

To this user, UAC is an impediment to that process - now, instead of merely running the administrative tool she wants, she has to ask to be allowed to run it as administrator.

With UAC set to automatically elevate for administrators, however, she's far happier. Still not perfectly happy, because there are still occasions when she has to ask specifically to run elevated - when the program is capable of running as non-administrator, for instance. Such programs run as non-administrator by default, and don't elevate themselves. These programs are irritating to such a user.

Typically, such programs appear to break when run with UAC disabled (or set to automatically elevate) - they fail to run, sometimes with bizarre error messages, often just crashing through failure to execute some action that the developers expected would succeed.

Other causes of breakage could be when an application is registered to a user, and the licence information is written to a file in the Program Files folder - when you're running under UAC's protection, files in the Program Files folder may be virtualised (i.e. the program thinks it's accessing the file in the Program Files folder, but it's really accessing a file in the user's home directory tree), and when you're running elevated, those same file accesses are not virtualised.

So, voila, instant loss of licence information, saved settings, or any number of other files that the program expected to find in Program Files.

What can we learn from this?

So, the message is clear - for installations with administrators who like the system to let them be administrators, don't disable UAC, make UAC elevate silently for administrators instead.

This system works, too, for the restricted users. It allows them to operate as restricted users, except when they absolutely know they need to elevate. Over-the-shoulder elevation prompting is still available for them, should they need it.

What still needs to be fixed?

What this option doesn't do is cover what appears to be Microsoft's reason for creating the elevation prompts in the first place. Without UAC prompting at random points, the administrators in control of a system have no clear sign that they've just fired up "Mary Kate and Ashley's Dance Party of the Century" only to be forced to run it as an administrator.

Even supposing you figure out that there's a program you're using which doesn't adequately run in restricted user mode, or which doesn't elevate itself where necessary, where can you go to get assistance from the developers of the application?

Call support?

Microsoft's own support is an example of how off-putting such a process can be. Microsoft Money refused to update on one of our systems, and I eventually determined it was because the update needed to be elevated, but was expecting to find some files that were virtualised by UAC. It failed with a meaningless error message. To call support costs $25 for Microsoft to even pick up the phone - and if the support tech believes that this is an "advanced" issue, he may charge about ten times that much. Perhaps later, after they realise the problem is their own fault, Microsoft will refund you the money - but many small businesses and individual users don't have that sort of money to loan to Microsoft, or other vendors.

So, is there any good way to persuade developers to quit their bone-headed "start with most privilege" behaviour? Maybe Visual Studio and compilation tools should refuse to run in an administrator session. Okay, so perhaps that's not tenable, because there are development projects that do require you to be an administrator, because you're developing something administrative - but what measure would make developers do the right thing for security (and for their users) naturally?

File and registry virtualisation appears to be a messy kludge on top of the sledge-hammer of UAC elevation, whose primary design goal appears to be to irritate end-users enough to persuade developers to stop doing the kind of things that requires virtualisation as a workaround, and the kind of things that requires administrator accounts in the first place.

Perhaps it's time that, instead of kludging for these bad developers, Microsoft simply said "It stops. Now." - if it's not registered (at install time, or by manifest) as an administration tool, it doesn't get administrative access - or virtualised access to HKLM or Program Files. Yes, that will mean admins will have two links to regedit, and similar tools - one to run in an administrator's session, giving access to HKLM, another to run in their user's session, giving access to HKCU.

UAC - The Emperor's New Clothes

Alun Jones — Thu, 24 Apr 2008 23:47:38 GMT

I heard a complaint the other day about UAC - User Account Control - that was new to me.

Let's face it, as a Security MVP, I hear a lot of complaints about UAC - not least from my wife, who isn't happy with the idea that she can be logged on as an administrator, but she isn't really an administrator until she specifically asks to be an administrator, and then specifically approves her request to become an administrator.

My wife is the kind of user that UAC was not written for. She's a capable administrator (our home domain has redundant DCs, DHCP servers with non-overlapping scopes, and I could go on and on), and she doesn't make the sort of mistakes that UAC is supposed to protect users from.

My wife also does not appreciate the sense that Microsoft is using the users as a fulcrum for providing leverage to change developers to writing code for non-admin users. She doesn't believe that the vendors will change as a result of this, and the only effect will be that users get annoyed.

But not me.

I like UAC - I think it's great that developers are finally being forced to think about how their software should work in the world of least privilege.

So, as you can imagine, I thought I'd heard just about every last complaint there is about UAC. But then a new one arrived in my inbox from a friend I'll call Chris.

"Why should I pretend to be different people to use my own PC?"

I must admit, the question stunned me.

Obviously, what Chris is talking about is the idea that you are strongly "encouraged" (or "strong-armed", if you prefer) by UAC to work in (at least) two different security contexts - the first, your regular user context, and the second, your administrator context.

Chris has a point - you're one person, you shouldn't have to pretend to be two. And it's your computer, it should do what you tell it to. Those two are axiomatic, and I'm not about to argue with them - but it sounds like I should do, if I'm going to answer his question while still loving UAC.

No, I'm going to argue with his basic premise that user accounts correspond to individual people. They correspond more accurately - particularly in UAC - to clothing.

Windows before NT, or more accurately, not based on the NT line, had no separation between user contexts / accounts. Even the logon was a joke - prompted for user name and password, but if you hit Escape instead, you'd be logged on anyway. Windows 9x and ME, then, were the equivalent of being naked.

In Windows NT, and the versions derived from it, user contexts are separated from one another by a software wall, a "Security Boundary". There were a couple of different levels of user access, the most common distinctions being between a Standard (or "Restricted") User, a Power User, and an Administrator.

Most people want to be the Administrator. That's the account with all the power, after all. And if they don't want to be the Administrator, they'd like to be at least an administrator. There's not really much difference between the two, but there's a lot of difference between them and a Standard User.

Standard Users can't set the clock back, they can't clear logs out, they can't do any number of things that might erase their tracks. Standard Users can't install software for everyone on the system, they can't update the operating system or its global settings, and they can't run the Thomas the Tank Engine Print Studio. [One of those is a problem that needs fixing.]

So, really, a Standard User is much like the driver of a car, and an administrator is rather like the mechanic. I've often appealed to a different meme, and suggested that the administrator privilege should be called "janitor", so as to make it less appealing - it really is all about being given the keys to the boiler room and the trash compactor.

It's about wearing dungarees rather than your business suit.

You wear dungarees when working on the engine of your car, partly because you don't want oil drops on your white shirt, but also partly so your tie doesn't get wrapped around the spinning transmission and throttle you. You don't wear the dungarees to work partly because you'd lose respect for the way you look, but also because you don't want to spread that oil and grease around the office.

It's not about pretending to be different people, it's about wearing clothes suited to the task. An administrator account gives you carte blanche to mess with the system, and should only be used when you're messing with the system (and under the assumption that you know what you're doing!); a Standard User account prevents you from doing a lot of things, but the things you're prevented from doing are basically those things that most users don't actually have any need to do.

You're not pretending to be a different person, you're pretending to be a system administrator, rather than a user. Just like when I pretend to be a mechanic or a gardener, I put on my scungy jeans and stained and torn shirts, and when I pretend to be an employee, I dress a little smarter than that.

When you're acting as a user, you should have user privileges, and when you're acting as an administrator, you should have administrative privileges. We've gotten so used to wearing our dungarees to the board-room that we think they're a business suit.

So while UAC prompts to provide a user account aren't right for my wife (she's in 'dungarees-mode' when it comes to computers), for most users, they're a way to remind you that you're about to enter the janitor's secret domain.

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.

Get Well Scotty McLeod

Alun Jones — Fri, 01 Feb 2008 06:46:44 GMT

I could have titled this "adversity shows how small our world truly is".

I had no idea that so many of my friends, acquaintances, MVPs and Microsoft staff are also friends with Scotty McLeod - until he got hit by a train last week.

He is recovering, and I hope to see him sitting up and arguing the toss with me when I visit the UK in a couple of weeks.

Until then, I'm left amazed at how many familiar names pop up when I search for "Get Well" and "Scotty McLeod".

Here's hoping he's quickly on the mend.

Why you don't run as root

Alun Jones — Sat, 12 Jan 2008 05:03:12 GMT

[... or administrator, or whatever]

I like Roger Grimes, he's a nice guy, and he generally makes me think about what he has to say. That's a good thing, because otherwise he'd either be part of the same choir as me, or he'd be the sort of guy whose ideas I dismiss with a wave of the paw and a barely audible "Pah."

Today, though, I think he's missing something fundamental - and perhaps you are too.

He writes in the InfoWorld Security Adviser column that "UAC will not work", on the simple basis that malware can still do all the things it wants to do without having to execute under a privileged account.

That's true, and it always will be - the day that a computer can see my attempt to "delete the Johnson account, and forward that instruction to the following addresses", and determine whether it's malicious or appropriate, is the day when the computer can do the whole job for me, by simply choosing all possible actions and seeing which are malicious and which are appropriate.

However, what I can rely on, if the malware has been held out of privileged accounts, is the integrity of the system, and (unless they were prone to activating the same malware) the other users on that system. [By system, I may mean one machine or several networked together to perform a function.]

So while it's true that the old cross-platform virus "forward this message to everyone in your address book, then delete all your data" is still going to function if the user stays out of administrator roles, at least the operation of the system can be restored, as well as whatever data has been backed up.

You don't run as a restricted user to prevent viruses from happening - you run as a restricted user to prevent viruses from happening to the people and systems with whom you work. You run as a restricted user, so that when some system falls over, you can say "it couldn't possibly have been me". You run as a restricted user because if there is a bug in the program you run, its effects will be limited to only that portion of the OS and its data to which you are restricted.

Sure, least privilege is somewhat of an artificial construct - but the alternative is that users get more privileges than they need. That quickly boils down to "everyone can do anything".

I've been on that kind of a network before, and when we found one guy's stash of truly offensive porn (this wasn't the occasional Rubens painting) on the server, we had no way of finding out who it was, let alone punishing them by firing them. The company I worked for was fortunate that whoever found it didn't sue for fostering the creation of a hostile workplace.

So, no, UAC won't stop malware - but then that's not its purpose. It's purely a beneficial, incidental, and temporary side-effect that it will stop much of today's malware.

How broken is the banking system?

Alun Jones — Tue, 08 Jan 2008 05:22:01 GMT

My kid and I love watching Top Gear - me, because it's nice to see him interested in a very traditional British TV programme (in the US, you can find it on BBC America), and him, because he just loves cars - particularly high-performance ones.

So I have to admit to having a little chuckle as I find what's been going on in the life of its host, Jeremy Clarkson.

Well, in the wake of the recent loss of 25 million child benefit case records by the UK Government's HMRC (tax and customs) department... what, you didn't hear about it?

Okay, I'll admit, I didn't report on it, because I figured the world and his wife had already heard all there was to hear on the story. Cut to the chase - someone at the HMRC received a call from someone at the NAO (National Audit Office), asking for some records. Rather than asking if they were supposed to be handing those records over, or if the NAO actually had any rights to receive the records, the "junior official" involved sent a couple of disks ... in internal mail (which turned out not to be so internal, having been contracted out to a courier) to the NAO.

The NAO called back after a few days, asking where their data was.

The junior official sent another copy!

At this point, somebody told someone, and a big stink got raised that there was all this data out there - 25 million records, 7.5 million families, containing names, addresses, bank account numbers, national insurance numbers (NI numbers - that's our equivalent of Social Security Numbers or SSNs).

Okay, so in the wake of all this, lad Jeremy decides he's fed up of all the press coverage of the waste of time investigation into the whole loss of two miserable little CDs.

He declares, in one of the UK national newspapers (the one with semi-naked women on one of its inside pages), that it's all a load of fuss over nothing - even goes so far as to call it a "palaver" (which is not, apparently, a knitted garment - that would be either a pullover, or a balaclava).

Mr C even goes so far as to publish his own bank account number. With sort code (aka bank routing number, to those of us in the USA).

"All you'll be able to do with them is put money into my account. Not take it out. Honestly, I've never known such a palaver about nothing,"

See - I told you he called it a palaver.

Sadly, as the BBC (don't they broadcast Top Gear, or something?) reports, "Clarkson stung after bank prank". I guess we couldn't predict that.

"I opened my bank statement this morning to find out that someone has set up a direct debit which automatically takes £500 from my account,"

After explaining to some disbelieving friends how this could have happened, I realised that not everyone has had the chance to run their own business, and see what a mess the banking system is. We all assume that the banks have our best interests at heart, and operate securely in ways that ensure we can't lose a penny.

Not really, no. They work (mostly) on the basis that it's cheaper to refund your money if you notice a problem and complain, than it would be to fix the problem in the first place.

Here's a simple explanation of how "direct debit" (in the US, "automated payment") works:

Most commonly you would complete a written Direct Debit Instruction, obtained from the organisation you wish to pay and return it to them for onward transmission to your bank. Some direct debits may be set up over the phone or via the Internet. In these cases the organisation must subsequently write to you confirming what has been agreed.

So, the receiving organisation claims to the bank that someone claiming to be the account holder requested them to withdraw money from the account.

Note "claims", because there's no proof at that stage.

It's not even as workable as "you write to the bank requesting they allow a direct debit from your account" - the bank has no opportunity to interact with the customer except by sending them their next bank statement!

That's broken - but then again, I've written before about how broken the credit card system for web purchases is. Again, the actual issuing bank, the one with whom you have a relationship, and who could validate your identity, is kept out of the transaction until it's already finished.

What would be super is if a celerity like Jerembly Clarkson would start a campaign to have the banks be required to all team up and do a properly secure set of protocols for credit card and payment authorisations. Then merchants like me wouldn't whine about repeated charge-backs that we can't actually refute, and people like him, ignorant about the truth of the banking industry's inability to secure the very money they are entrusted with, wouldn't go handing out money willy-nilly to random charities just to prove that his trust is woefully misplaced.

I just don't think it'll happen.

I hope there was only £500 in the account, and that Mr Clarkson has already closed that account, and opened one whose number he will keep secret, sharing only with the bank, the company that prints his cheques, everyone he ever pays by cheque... now there's another broken system.

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.