Tales from the Crypto : Things I Learned At Microsoft

Microsoft TechFest

Alun Jones — Tue, 03 Mar 2009 23:45:49 GMT

Last week, I went to Microsoft’s TechFest as part of their “Public Day”. This is the first time MVPs as a group have been invited to this event, and although it’s clear we missed some of the demonstrations that are not public-ready, this is something that I hope can be extended to us in future, even if only to Washington-state MVPs

For general news links on MS TechFest 2009, you can search news.google.com for “TechFest”. Here’s a couple of samples:

http://www.king5.com/video/index.html?nvid=335707 – I didn’t see these guys there.

http://www.guardian.co.uk/technology/blog/2009/feb/25/microsoft-software - I bumped into this guy.

I also saw Chris Pirillo there from LockerGnome and Chris.Pirillo, but he hasn’t written anything yet. I only mention him because it’s about time that I thanked him for being one of the earliest online writers (they were called “e-Zines” back then, apparently) to mention WFTPD in his column. Sadly, I don’t have a copy to remember what it is that he said :(

Apologies to anyone who expected to reach me by email that day – the usual computers spread around the Microsoft Conference Centre for email and web browsing were missing, possibly because the Press were there, and they’ll steal anything that isn’t nailed down, before coming back with crowbars.

So, here’s some description of the things I saw, ranging from the exciting and relevant to the “why is Microsoft spending money on that?” [Note that this is not meant to be disrespectful of ‘pure research’ – often, today’s “useless meanderings” become tomorrows product – WFTPD itself started from a momentary “how hard can it really be?” lapse in my own judgement, followed by a little research and a lot of effort.]

Specification Inference for Security: To improve focus on potential security faults in static analysis tools, this is a toolset whose approach is to divide functions into Sources, Sinks and Sanitizers (although that alliteration is liable to lead to confusion) – Sources generate untrustworthy data from input, Sinks consume data that they trust will fit their expectations, and Sanitizers transform the data along the way, ideally making sure that it goes from untrustworthy to trusted. Thinking in terms of a SQL injection, the Source would be a web server receiving input from a user containing a SQL command, the Sink would be the SQL server, and the Sanitizer would be whatever code packages the input and determines whether to pass it to the SQL server, and what changes to make (such as requiring proper quoting, or using a stored proc or parameterized query). Once these categorizations have been made, the static analysis tool can check that Sanitizers actually do sanitize – rather than having to try and analyse every function for possible sanitization. http://research.microsoft.com/merlin
Concurrency Analysis Platform and Tools: Enhances your test tool set by allowing tests to run with multiple permutations of concurrency. Race conditions are usually caught by users, or in production environments, because the environments cause different threads or processes to run at different speeds – with this toolkit, you get to try out multiple combinations of execution sequence, so that you are more likely to trigger the race condition. Of course, you still have to write tests that consider the prospect of doing more than one thing at a time, and because there are a large number of concurrency permutations, it’s not a turn-key solution, but it does allow you to debug concurrency issues more methodically, and catch those that appear more frequently. http://research.microsoft.com/chess - and this one’s available for download as an add-on to Visual Studio!
Lightweight Software Transactions for Games: Not just for games, the ORCS platform (Object-based Runtime for Concurrent Systems) makes coding multi-threaded applications easier and more problem-free. http://research.microsoft.com/orcs
Closed-Loop Control Systems for the Data Center: Power consumption monitoring and control allows for servers to be brought online or offline as computing demands change, so that as usage ramps up, more servers are turned on, and as usage declines, servers are turned off. I don’t think this is entirely original.
Algorithms and Cryptography: Cryptographic solutions with leakage. Unfortunately, the lady who came up with this wasn’t on hand to discuss her work, and her husband standing in for her didn’t seem to understand much about it either. The poster claimed an algorithm whereby you could leak some of your key to an attacker without reducing the strength of the key. I’m not sure how this works, or where it differs from having redundant information in the keys, or something like M of N crypto, but maybe it’ll be something that will affect our field in the years to come.
Opinion Search: Full of marketing jargon and too dense for me to penetrate, this is something that we could potentially use in the business side of Expedia, making use of customer opinions to allow search results to match the user’s opinion against the opinions of others with whom they have consistently agreed in the past, and can be expected to do so in the future.
Low-Power Processors in the Data Center: Using Netbook processors for data processing in a parallel environment allows for significant power savings.
Audio Spatialisation and AEC for Teleconferencing: Relying on the rise of computer-phone integration, and the fact that most computers have stereo speakers, this is a system for teleconferencing where different parties are given a different spot in the stereo spatialisation. Makes it much easier to tell who’s talking.
SecondLight: Surface computing taken to another level, literally. The surface on which images are projected is usually a light diffuser, so that the image effectively “stays” on the surface. In this implementation, the surface is rapidly switched between diffuse and transparent, so that you can use a secondary diffuser surface on top, which shows a different image. You have to see a demonstration to understand it - mms://wm.microsoft.com/ms/research/projects/secondlight-cambridge/secondlight.wmv - it’s a little flickery, in real-life too, but the team assured me that it can be made less so.
Commute UX – Dialog System for In-Car Infotainment: Will this stop executives requesting shorter passwords for unlocking their phone while driving? Probably not.
Back-of-Device Touch Input: Anyone using an iPhone or similar touch-based device will be familiar with the issue that your fingers are covering the image you’re trying to manipulate. By putting a sensor panel on the back of the device, you can reduce the size of the display without making it impossible to read while you select.
Augmented Reality: Combining GPS location with stock footage of the place you’re in, this is all about placing extra information into a view (such as a cell-phone with a video camera, or maybe eventually a heads-up display in glasses / goggles) of the world around you, by recognising where you are. Can be used for games, directions, advertising, city guides, or post-it notes without the paper.
Recognizing characters written in the Air: Entertaining just to watch people dragging an apple around to make letters on a screen in front of them. Probably more useful in the mode where the lid of an OHP pen is the “bright spot of strong solid colour” being tracked in mid-air.
Colour-structured Image Search: Draw a rough colour picture of the image you want to see, and get a page of search results from around the web. The demonstrations consisted of drawing pictures of flowers, or flags, or a sunset. I foresee widespread abuse once deployed, although it will mean that people who usually draw on bathroom walls will be moving their talents online.

MVP Summit 2009 is here!

Alun Jones — Mon, 02 Mar 2009 18:44:06 GMT

I snapped this picture last week at Microsoft' Research’s Tech-Fest event.

Microsoft always makes the visiting MVPs feel welcome at Global Summit time, when all MVP awardees are invited to visit Microsoft’s campus, and engage in face-to-face conversations with various Microsoft Product Groups about the feedback they’re seeing from the users they talk to in their various forums, whether that’s Usenet newsgroups, web forums, user groups, or book and magazine readers.

This year, in large part thanks to the efforts of one of the other Security MVPs, Dana Epps, we have a fantastic schedule of in-depth sessions on identity frameworks, threat modeling, Microsoft’s internal security, and a number of other topics that I should perhaps keep quiet about.

The other benefit to me, as an MVP, from these sessions is that I get to network with other MVPs – all of whom are intelligent, driven individuals with expertise in a wide variety of fields, not just my own area of Enterprise Security.

Already I’ve spoken to a number of people in conversations that I intend to continue long after the Summit is over. I’ve made some new friends, met plenty of old friends, and expanded and strengthened existing social connections.

It’s a little sad that the worsening economic climate has caused a number of MVPs from outside the US to not attend this year’s Summit, and even some from inside the country. But it does appear that the MVP programme is still strong, as around 1500 MVPs from around the world are in attendance.

For those wondering about the swag bag, we got a cloth bag, stickers, a pen, and a water bottle. The shirts will be arriving on Wednesday (thank you, US Customs!). The benefit is more in the programme of technical sessions than the bag, unlike some technical conferences, where your $2500 entrance fee gets you a rather spectacular bag of ‘freebies’ and a number of sessions scheduled such that all the ones you want to see are in the same time slot.

I have to say, I love the stickers. Being a part of the MVP programme is a really nice thing that Microsoft does to say ‘thank you’ to people who are assisting Microsoft’s customers in newsgroups, user groups, etc, and who would continue to do so anyway, even if Microsoft ended the MVP programme. As such, I think it’s an excellent recognition, and I’m proud of the fact that I was awarded – so I like to show it off, mainly by plastering stickers on my various technology items like laptops and PDAs.

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.

Silently fixing security bugs - how dare they!

Alun Jones — Tue, 22 Apr 2008 22:06:30 GMT

Over in "Random Things from Dark Places", Hellnbak posts about reducing vulnerability counts by applying the SDL (Security Development Lifecycle), and makes the very reasonable point that vulnerabilities found prior to release by a scan that is part of the SDL process cannot be counted as failures of the SDL process. What's more, those vulnerabilities can be silently fixed by the vendor before shipping / deploying the product being reviewed. [Obviously, not fixing them would be a really bad idea]

What intrigued me, though, was this line:

But, as Ryan [Naraine] said — issues found in public code that are fixed silently are a real issue. While I have picked on Microsoft specifically for this practice the sad reality (that I quickly learned after publicly picking on MS) is that pretty much all vendors do this.

So, let's see now... this is talking about a patch, hotfix, or service pack, that removes a security vulnerability from a product, but where the vulnerability (and its fix) does not get announced publicly.

There are two reasons not to announce a security vulnerability, in my view:

You don't want to.
You can't.

Let's subdivide reason 1, "You don't want to":

You feel it would adversely affect public opinion, stock price, user retention...
Well, that's kind of bogus, isn't it? Given some of the vulnerability announcements that have appeared, what on earth could be worse than remote execution, elevation of privilege, and complete control over your system? The only way to make this accusation is to assert that the vendor randomly picks vulnerabilities to announce or not announce, to somehow reduce the overall numbers - and then manages to do so in such a way that noone else notices the vulnerability that was fixed.
That's not security, and any vendor who did that would find its security staff soon revolting against that practice. There isn't enough of a glut of security workers to be engaging in a practice that assumes you can hire more to replace the disgusted ones that quit.
You're tired of going through the process of documenting the bug, its workarounds and/or mitigations, and would rather be doing something else, like, oh, I don't know, fixing more vulnerabilities.
That's not good security - create a more streamlined and automated process for creating the announcements, and do both - find and fix more vulnerabilities and make announcements for the ones you find. If you're too busy to announce all the vulnerabilities in your product, you're too busy to fix them all.
You found the vulnerability internally, and would like to prevent it from being exploited, by releasing the patch along with an announced fix and hoping people install it.
That's not terribly reliable as a patching policy. It makes some small sense for related fixes, but then why wouldn't you announce that as a related fix in the related announcement? Perhaps it makes sense for architectural fixes, where the only good fix is to go to the next level of service pack, but then wouldn't you want to publicise workarounds for those who can't apply the next service pack for one reason or another?
But the biggest reason not to do this is that when you release a patch, people will reverse-engineer it, to figure out how to exploit the unpatched version - and they'll find the change you didn't mention as well as the one you did, and will exploit both of them. But your users will only be aware of one problem that needs patching, and may have decided that they can mitigate that without patching.
So, pretty much bad security on that approach, too.

So, "You don't want to" comes out as bad security, and it's the sort of bad security that you would have to fix to employ - and continue to employ - a halfway decent security team.

What about "You can't" - how could that come about?

You have a legal judgement or contract requirement forbidding you from disclosing vulnerabilities. Hey, Microsoft has some of the best and most expensive lawyers on the planet, but even they get stuck with tough legal decisions that they have to abide with, and can't do anything about. If a security vulnerability was considered to be a "threat to national security", the current administration (and possibly many others) would be only too quick to deem it so secret that no-one could reveal its presence. And once you accept that possibility, it isn't hard to think of too many circumstances where a company might be forced to keep a vulnerability quiet.
You know enough to fix the code, but not enough to classify the vulnerability or explain its workarounds or mitigations.
Yeah, that's pretty much the truth for all the announced vulnerabilities, too - how many times have you seen a vulnerability announcement that says "this cannot be exploited remotely", followed by one a few days later with updated information that reveals that, oh yes it can. This doesn't appear to be a good reason not to announce a vulnerability.
You don't know the vulnerability is there, or you don't realise that you fixed a vulnerability.

Okay, that last one's the topper, isn't it? How can you announce a fix for a vulnerability that you don't know about?

Clearly, you can't.

Just as clearly, perhaps you're thinking, you can't fix a vulnerability that you don't know about, right?

Wrong. You can very easily fix a vulnerability about which you know nothing. Here's a couple of hypothetical examples:

After we moved into our new house, we changed all the locks on the doors. Why? Because the new locks were prettier. In doing so, we fixed a vulnerability (the former owner could have kept the keys, and exploited us through the old locks) - but we didn't intend to fix the vulnerability, we just wanted prettier locks.

Years ago, I needed a piece of functionality that wasn't provided by the Win16 API, so I wrote my own routine to do file path parsing. A couple of years back, I dropped support for Windows 3.1, and in a recent code review, I spotted that the file path parsing routine was superfluous. So I removed it. In removing it, I didn't spend a lot of time looking at the code - there was a vulnerability in there, but who does a code review of a function they're removing? So now, I've fixed a vulnerability that I didn't know existed.

Too many times, we assert evil intent for those actions that we disagree with. Ignorance is a far better explanation, along with incompetence, expediency, and just plain lack of choice. Note that ignorance is no bad thing - as in my hypothetical case, a genuine attempt to improve quality leads to a security improvement of which the developer was wholly ignorant.

Whether vendors don't want to disclose all of their vulnerabilities when patching, or simply can't, because they didn't realise the scope of a fixed vulnerability, it's important to stay current with patches wherever that would not interfere with your production applications. Because one day there will be a flaw patched, which your company will be attacked through. If you didn't apply that patch, you will be owned.

Google on Microsoft / Yahoo! Deal: "Wah!"

Alun Jones — Mon, 04 Feb 2008 20:21:00 GMT

In case you've been under a rock, Microsoft appears to be trying to take advantage of Yahoo! Inc's recent poor performance to make an unsolicited offer (as far as I can tell, it's not a hostile bid until and unless Yahoo! officers declare that they will be fighting against it by offering a deal they think their stockholders will prefer) to buy the company.

Clearly, given Microsoft's intent to compete with Google, this is a great move for Microsoft - the Microsoft search engines have always lacked popularity compared to Google, and Yahoo!'s engines are still hugely popular. With Yahoo!'s large user base for other web pages, this acquisition amounts to a huge number of eyeballs to which Microsoft can expose their Internet product strategies.

Google, obviously, is a little perturbed by this.

How do they choose to express their concern?

By pointing to the openness and innovation which has underscored the Internet's development throughout the years, and which has been the reason that the Internet has remained popular and usable.

Now, I will definitely agree that Microsoft is known for locking up many of their most interesting innovations inside of patents.

However, the company is also very well known for contributing technical standards to the Internet body of knowledge as expressed in the Internet RFCs.

Let's see how innovative and open Google has been, by searching for "Google" in the Internet RFCs - let's see how many employees have written these open and innovative documents.

RFC 4473: "...search engines such as Google." is the only occurrence - so it's not written by a Google employee.
RFC 4646: Tags for Identifying Languages - authored by Yahoo! and Google employees.
RFC 4647: Matching of Language Tags - essentially part II of RFC 4646, by the same authors.
RFC 4657: Contributors include a Google employee
RFC 4772: Notes that Google was searched.
RFC 4693: An administrative note about the IETF, written by a Google employee.
RFC 4838: Delay-Tolerant Networking Architecture - technically, Vint Cerf was a Google employee at the time, but appears to have done this as work for JPL.
RFC 4954: An authentication extension for SMTP, co-written by a Google employee.
RFC 4959: Authentication extension for IMAP, co-written by a Google employee.
RFC 4981: Refers in passing to Google.
RFC 4990: Use of addresses in GMPLS Networks, co-written by a Google employee.
RFC 5023: The Atom Publishing Protocol, co-written by a Google employee.
RFC 5034: POP3 Authentication extension, co-written by a Google employee.
RFC 5050: Vint Cerf of Google is listed as a contributor.

So, the number of RFCs listing Google employees as authors or co-authors is nine. If you are ruthless in your search for originality, and cut out RFCs that appear to be copies or extensions of other Google employee RFCs, as well as those that were written for other employers than Google, you get five. And one of those is a note about the way in which the IETF operates.

What about Microsoft - when have Microsoft employees ever contributed time to the development of Internet RFCs?

Compared to Google's fourteen matches in the RFCs, "Microsoft" is found hundreds of times. So I tried to limit my search to RFCs that were likely written by Microsoft employees - a good search term for this is to find those RFCs in which either "Microsoft" or "Microsoft Corporation" is at the end of a line. I further limited the search to documents where this match was found in the first 25 lines.

175 RFCs.Okay, so maybe some of those were duplicates, or unimportant ones, and Microsoft have certainly been doing this longer than Google.

Google's first employee-written RFC came in September 2006, so in eighteen months, they've written at most nine, at a rate of one every two months; Microsoft's first is dated December 1995 - that's 146 months ago, so that Microsoft employees are producing RFCs at a rate of slightly more than one every month - more than twice as fast as Google.

I think that if Google wants to cry "shame" that Microsoft is not open or innovative, and that this will cause the Internet to shrivel, they should perhaps start with a little introspection.

Buying an Internet founder does not make you into a founder of the Internet.
Buying an RFC author does not make you open and innovative.
Complaining that a competitor's proposed acquisition will stifle openness and innovation only makes sense if you are, by comparison, a champion of those two qualities - by comparison through the reading of RFCs, Google appears somewhat secretive and dull.

P.S. Please don't comment in this entry about "embrace and extend" - let's face it, openness and innovation as they apply to the Internet are all about "embrace and extend" - Internet standards are published so that they can be adopted and advanced. This discussion is not about whether Microsoft copies from other companies - after all, if this is all about openness and innovation, copying is a good thing.

Waiting for Vista SP1?

Alun Jones — Fri, 18 Jan 2008 05:24:31 GMT

In a previous article, I wrote about how to sound stupid by saying "let's wait for Service Pack 1 before we deploy Windows Vista".

Now here are a few ways to sound clever, by pointing to specific issues that will be fixed by Windows Vista SP1.

GPMC.MSC (the Group Policy Management Console) gets removed, and the Group Policy Editor will default to editing the local group policy only. Okay, that's not really an advantage - but you will be able to download a newer group policy editor later.
Allows Remote Desktop Protocol (RDP) files to be signed. Complains when they aren't (though this does cause a problem for Remote Web Workplace users in SBS land, because there's no way to actually sign the RDP files!)
Improved cryptographic random number generator, leveraging the TPM if you have one on your computer. (Not sure there was that much wrong with the old one... but this one's better, and more ... cryptographicky)
BDE + TPM + USB + PIN - need I say more? Oh, okay then - for the truly security paranoid, you can use Bitlocker Drive Encryption with the Trusted Platform Module, and have it require a USB key and a PIN before the system will start.
Also with BitLocker, there is support for encryption of drives other than the main boot volume (which is the volume that has the system software on it, not the system drive, which is the one you boot from). Still can't encrypt the system drive - because that would be just plain stupid.
Performance improvements - really, what's not to like with an update that makes your computer go faster?
exFAT file system for flash memory storage - you probably haven't exactly been drooling about this.
SSTP - allows VPN over HTTPS to Windows Server 2008 systems. Yeah, because if you're holding off installing Vista until SP1 ships, you've got loads of those ready to use, right?

I don't know - were any of those features worth waiting for? I know there's performance and reliability improvements, but those are somewhat nebulous and indistinct.

My advice is still to test Vista as it shipped, test Vista with the Service Pack 1 Release Candidate - report bugs to Microsoft quickly, before they lock it down - and then when SP1 releases, and then test with Vista SP1 RTM when it comes out... and stop letting vendors get away with saying that "all you need to do to run our software on Vista is to disable UAC, or make all users administrator" - that's just plain bad.

What do I wish was in SP1?

Some provision for solving the EFS incompatibility between XP and Vista (maybe XP SP3 will help, I don't know)
The ability for a standard user to back up his own files, including EFS encrypted files, so that a user can export encrypted data to removable physical media (like a CD-R). Too much data still travels unencrypted, and it might help to have the ability to put encrypted files on CD-Rs using only what comes with the OS.
A server administration toolkit that allows me to administer Windows versions 2000, 2003 and 2008 from Vista.
An ability to switch sound output devices on already-running applications. When my wife comes into the office, I want to stop using the built-in speakers and start using the Bluetooth headset, so that she can't hear me playing Halo.

So, tell me, what are you waiting for?

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 many people do you represent?

Alun Jones — Fri, 23 Nov 2007 06:44:31 GMT

In my earlier discussion on why 100% utilisation is not maximum efficiency, I alluded to the fact that a rejected customer, or a customer with a bad experience, will tell other potential customers that you never get to see.

This reminded me that there are a myriad of connections that we have to other people around us, and that this should always be recognised when considering how best to serve a customer.

As a business example, my FTP server, WFTPD, has been sold to over 10,000 customers, some of whom have purchased hundreds of licences. Most of those large sales were preceded by a sale of a single licence that I believe led directly to the larger sale. So to me, every single sale represents a potential of hundreds of licences.

Of course, to Microsoft, I represent in some small way those 10,000 customers, all of whom use not only my software, but the operating system and network components on which my software runs.

In the sphere of community, this is why MVPs are considered so valuable by Microsoft. Whereas most customers represent themselves, or possibly a department or a company, MVPs represent those members of the community that they assist - and that generally means dozens, hundreds, possibly thousands of individuals or companies.

I like to think they listen to us - they certainly spend enough time asking us questions, and getting our opinions.

Let's just wait for Service Pack 1

Alun Jones — Thu, 30 Aug 2007 13:08:19 GMT

Every so often, I'll hear it said, and frequently not in jest, "let's wait until Service Pack 1 before we deploy Vista", or sometimes "Server 2008".

While it's true that Microsoft has indeed announced plans to test, and then release, Windows Vista SP1 early in 2008, I have to say that I don't find this thinking any smarter than the old "let's buy IBM" idea, based on the "Nobody Ever Got Fired For Buying IBM" principle.

Even if it were true, someone's eventually going to realise that if it's your job to specify what the IT budget gets spent on, and you say things like "we'll deploy it after Service Pack 1", you're just not acting as if you're doing your job.

Somebody, one day, will call your bluff, and say "Why? What bug is a showstopper for deploying Vista RTM, and why do you believe it's fixed by SP1? Why didn't you find that bug out while you were beta testing the operating system? Weren't you beta testing the operating system?"

And you're going to look foolish, because you don't have anything in particular to point to (UAC? That's a bit generic - you have to say what you don't like about UAC, and why you think SP1 will make it all better) in order to defend your mindless parroting of "let's wait for SP1".

For the record, there are reasons to anticipate SP1 - it adds an SSL-based VPN capability, through the SSTP, and it allows you to encrypt multiple drives using BitLocker through the UI (you can use manage-bde.wsf to encrypt multiple drives using BitLocker from the command prompt).

There are other features in SP1, and you should definitely consider whether you can use those features. But there really isn't any break-fix that makes it important for you to stop testing and planning to deploy Vista RTM while you wait for SP1.

Are you a 'dual'?

Alun Jones — Thu, 30 Aug 2007 04:08:54 GMT

Last month at Tech-Ed, I was discussing with someone from the Solution Accelerators team about how I wished that Microsoft would produce some administration documentation for developers, and/or developer documentation for administrators, so that the two groups would be able to talk the same language.

[As a f'rinstance, back in the days of Windows 2000 and before, if you were a developer writing code to log a user on to the system and run a process (say, for instance, in your spiffy little FTP server), you would face an error if your code wasn't running in the context of an account with SE_TCB_NAME privilege.

But you couldn't tell an administrator to enable the SE_TCB_NAME privilege on the application's account, because he'd have no idea what you mean.

To an administrator, that privilege is called "Act as part of the operating system".]

"Well," said my conversational partner, "That's because you're a jewel."

"That's awfully nice of you to say, you're somewhat of a gem yourself."

"No, not 'jewel', a 'dual' - you span the two worlds of IT Pros and Developers."

He went on to explain that there are few duals, and that this was why there were few resources that address the disparity between what is developed, and what is administered.

A lot of the examples I came up with (e.g. the name LUA versus UAC) were rooted in the history of development - where Microsoft's naming police have chosen a name that they felt was "catchier", "more marketable", or simply "not offensive to <some-group>", as a replacement for an internal name. Changing the internal name in APIs that have already gone through beta testing is not generally possible, so the developer name stays as the old name, and the administrative interface is changed to present the new, marketing- and legal-friendly name or image.

Are you a dual? What are some of your challenges in communicating across the boundaries between two worlds?

Larry Osterman isn't that into you, either.

Alun Jones — Thu, 23 Aug 2007 04:53:51 GMT

In previous articles, I've pointed out:

All of these are on the basic theme that developers should be aware that many users - possibly even most users - possibly even most of their users - are not going to spend a majority of their time running software written by those developers.

I pick on Apple for this because it's fun to do so, and because their attitude seems to me to be that they know what's best for their users, and the users have no right to choose anything different. That's insulting to power users - hey, it's insulting to many novice users, too.

But it's not just Apple who exhibits this attitude. For instance, on my laptop, I have this icon in my notification area called "HP Digital Imaging Monitor" . Clicking on it does nothing, right-clicking on it does nothing, and I can't say that I remember it ever doing anything other than sit there staring at me.

I can at least disable some of the icons that bother me by their presence in the notification area (but have I disabled the processes they represented?) - but the point is that there is a pile of crap on my machine that I almost never use.

Quite honestly, I've gotten into the habit of downloading a fresh copy of QuickTime, or RealPlayer, whenever I need to play one of their format files, and then uninstalling them again once I'm done.

What does it say about your code that a user would rather install and uninstall your program every time he wants to view your file format, rather than keep your software around?

And how easy is it then for that user to be distracted away from your code to someone else's that does the same job? Never give your users a good excuse to dump you.

But what does this have to do with the title of this blog posting?

I've just noticed that over the last several days, Larry, too, has been spouting off about his battles inside Microsoft to persuade his fellow developers that, quite frankly, your users aren't that into your code, and you shouldn't expect them to think it's as important as you do.

A natural consequence of this is that you should think very carefully when writing software, not to view it as the most important thing (which, being your baby, it quite obviously is), but to view it as something that a user might use once every six months.

Enough of me, then, go look at Larry's articles - he has some even more practical advice on crapplet mitigation:

Larry's one of my favourite bloggers - I almost always learn something from reading his posts.

firefoxURL:%03

Alun Jones — Fri, 27 Jul 2007 04:05:53 GMT

Part 3 - and I promise that's the lot for now, because it's starting to look like I'm obsessed or something.

Over the past week or so, you've read me talking about vulnerabilities in Fire fox's protocol handlers, and how my perception is that Internet Explorer is neither the source of the flaw. A few others have weighed in on the issue in various directions, some at their own blogs, and others shuffling from blog to blog leaving comments.

Now, I think it's time to look at Internet Explorer.

Some of my readers have suggested that I have been blinkered to what they see as Internet Explorer's failings in this conversation, and in a sense, they're right - I've been looking primarily at identifying where the actual security vulnerability lies, and deliberately not broadened my inspections to look at where related non-standard behaviour lies.

I've quoted RFC 3986 a couple of times, and in this article, it's worth pointing out that although I believe it is correct that Internet Explorer should not percent-encode the URIs that it passes on to protocol handlers, I also believe that Internet Explorer should not be percent-decoding the URIs passed to protocol handlers.

Sadly, this is not the case - Internet Explorer decodes percent-encoded values, and also has a habit of percent-encoding some URIs on re-display. For instance, the URI "whatnot:hi there" becomes "whatnot:hi%20there" in the address display, even as it's passed unfiltered to the protocol handler.

Just as Internet Explorer has no way to know what the URI's intent in encoding is, it has no way to know what the URI's intent at decoding is, and should feed the URI unvarnished to the protocol handler, for the protocol handler to deal with as it will. At least the developer documentation for writing a protocol handler documents that Internet Explorer decodes percent-encoded values before handling them to the protocol handler - and this is likely a result of noting how few protocol handlers were written by people who read RFC 3986.

What isn't documented is that in addition to "%1", there are other substitutions that can be made in the command line. %d and %l (that's a letter 'ell') both appear to be the same as %1, as does %0, confusingly enough. %i gives some kind of identifier, in the form of :M:N, where N is the PID of the process that Internet Explorer is running - I have yet to figure out what M is. %s gives 1, and %h gives 0 - perhaps these indicate whether the handler is to be shown or hidden? Again, these are just guesses, and I have asked Microsoft if they can document these parameters.

Should Internet Explorer be changed?

So, now we've discussed that Internet Explorer decodes percent-encoded values on their way to the protocol handler, and encodes them on their way to the address bar, and I've stated my opinion that I think this is wrong. We've discussed that it's documented behaviour, but that Internet Explorer exhibits other behaviour that ought to be documented.

Others have discussed that Internet Explorer does not encode values on their way to the protocol handler, and that they think this is wrong.

First, let me re-iterate that while that is definitely opinion on their part and mine, and I can't call one definitively right or wrong, I am still going to say that Window Snyder is wrong to assess this behaviour as a critical vulnerability in Internet Explorer.

If Internet Explorer changes its behaviour, it will be as a convenience to the protocol handler developers, with the side effect of possibly protecting users from a small class of bugs in protocol handlers written by people with poor security skills (but not protecting against any number of wider classes of bugs that those developers might make). The critical vulnerability is still in any such exploitable protocol handler.

Many have pointed to Firefox's quick fixes to the handler calling encoding as an example that Microsoft should make these changes themselves, and that Microsoft's lack of change indicates a reluctance to address security.

We've seen a number of occasions where Microsoft has been quick to address security - and in a situation like this, you can bet that Microsoft staff have been asking the question "should we change this behaviour?"

If security was the only consideration, then making the change is still an unlikely decision - the flaw is not with Internet Explorer, and if you're going to argue that "defence in depth" suggests that Internet Explorer should accommodate flawed protocol handlers, then you're going to have to answer the question of whether you're going to patch this in the TCP/IP stack, the Ethernet drivers, the Linksys/Cisco routers... All of these feature significantly in the path under consideration, and to all of these, the possibility of a malformed URI triggering a vulnerability in a protocol handler is but a miniscule fraction of the work they do.

Every time you change code, you run the risk of introducing related - and unrelated - damage. For Firefox, that risk is relatively small - the code-base is known for being changed at the drop of a hat, and vendors and users aren't surprised to see weekly patches, some of which will kill functionality that they use. For Internet Explorer, there is a far greater expectation of stability. There is a far larger pool of documentation on its functionality, and if that documented functionality disappears or changes, users and developers call on Microsoft expecting assistance.

Don't forget, also, that every Windows Firefox user is also an Internet Explorer user, and as Jesper found when delving into the bowels of the most recent Firefox bugs, Firefox on Windows is an Internet Explorer user.

As a result of all these things, Internet Explorer is going to always balance security against compatibility and usability - and where the security problem is external to Internet Explorer, there's going to have to be a pretty powerful argument in place that Internet Explorer can best address the problem before changes will be made there.

To date, these exploits have centered around one vendor's code. Should Internet Explorer be pushing a disruptive change to everyone just because that vendor calls IE by rude names in reaction to its own flaws? Should a change be forthcoming as a result of seeing how incompatible the URI behaviour is with RFC 3986?

I don't think so. Maybe the next time significant disruptive change comes along - IE 8, perhaps. This time, why don't you all test your apps while it's still in beta, mm-kay?

firefoxurl: URL vulnerability

Alun Jones — Sun, 22 Jul 2007 20:57:00 GMT

Heard about the firefoxurl vulnerability?

It turns out that you can exploit Firefox by having Internet Explorer visit a link to a URL that starts with "firefoxurl:" (and a bunch of other code). [Assuming you have Firefox on your computer along with Internet Explorer]

This is because Internet Explorer blindly accepts and passes the entire contents of the URL to the handler for the firefoxurl URL type - that handler, as the URL scheme name implies, is Firefox. It's also because Firefox can be exploited by command-line parameters, because Firefox's protocol is handled by interpreting a command-line, and because Firefox interprets the command-line provided to it as if it is always well-formed.

There's been a lot of discussion about whose problem this is, and where it needs fixing. Jesper's a friend of mine, and I'm a fan of his, so I'd like to point to his posts on the discussion so far, here and here.

A number of people have made references to RFC 1738, and its description of which characters must, and may, be encoded in a URL. That's all very interesting , if you're engaged in academic discussion of how to create a URL, as the originator, or how to process it, as a consumer.

In this case, the discussion as to whether IE has a flaw should be centered on how much work an intermediary party should do when given something that is alleged to be a URL, before it hands it off to a third party for actual handling.

This makes this intermediary (Internet Explorer in the original exploit, but ... are there others?) behave like a proxy for such protocol handlers, rather than a consumer or provider of the URL as a whole.

I'm sure we'd have heard a different tale if Microsoft's Internet Explorer team had chosen to limit the set of characters that can be passed through to an underlying handler; instead we'd hear "why does my protocol handler have to interpret encoded character sequences? They weren't encoded in the link, and there's no reason for IE to encode them!"

As Markellos Diorinos, IE Product Manager, points out in the IEBlog, it's not just the presence of uncomfortable quote characters that the protocol handler will have to cope with, it's buffer overflows, invalid representations, and out-of-spec protocol portions of varying kinds. IE can't possibly know all the things that your application might find uncomfortable, versus all the things that your protocol may need, so it doesn't try to guess, or limit the possible behaviours of the protocol handler.

In short, IE does what any interface between transport layers does - it strips off the header ("firefoxurl:"), and passes the rest uninterpreted to the next layer. It is IE's job, in this case, only to identify (from the scheme specifier) which protocol handler to fire up, and to pass its parameters to it.

Perhaps you think that's not defence in depth - but then, defence in depth is not about enforcing the same defence at several layers, it's about using knowledge specific to each layer to protect against attacks within each layer. Sometimes those protections are redundant, but unless there is different knowledge in that redundancy allowing the layers to do different defence work, there is little value to redundancy for redundancy's sake.

Yes, the IE team could have decided that they'd enforce URL standards that were not being followed by the upstream provider (in this case, the creator of the link), and enforce them on the portion passed to the downstream, but such approaches tend to limit the flexibility of the protocol.

IE's responsibility is to ensure that any URL that comes to it does not trigger a vulnerability in IE, that any URL that comes from it conforms to RFCs, and that any information that is supposed to pass unmolested through it actually passes unmolested.

It's just a matter of some amusement that when Mozilla's Window Snyder, Chief Security Something-or-other, called out this lack of extra preprocessing as a specific vulnerability in Internet Explorer, she did not think to confirm first that Firefox itself did not contain the same behaviour. I will be interested to see how they address this - whether they will 'fix' the behaviour, and if they do, what will be the resulting impact on compatibility with existing protocol handlers whose programmers assumed that their data would arrive unmolested, as documented, and who have already taken appropriate security measures to cope with this (such as not parsing anything past the beginning of the user data as if it was anything other than untrustworthy user data).

Finally, as a nod to my own past as a nit-picker of RFCs, here's what RFC 3986, which obsoletes the generic URL specification portions of RFC 1738, has to say about intermediaries in the URI handling stream:

The URI syntax is organized hierarchically, with components listed in
order of decreasing significance from left to right. For some URI
schemes, the visible hierarchy is limited to the scheme itself:
everything after the scheme component delimiter (":") is considered
opaque to URI processing. Other URI schemes make the hierarchy
explicit and visible to generic parsing algorithms.

That suggests that a generic URI processor (such as a forwarding proxy) should see the URI after the scheme component as "opaque to URI processing" - in other words, that the processor should assume it can understand nothing about, and therefore should not inspect, the part after the colon.

Further down in the document:

Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form.

When a URI is dereferenced, the components and subcomponents significant to the scheme-specific dereferencing process (if any) must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be mistaken for component delimiters.

...Implementations must not percent-encode or decode the same string more than once, as decoding an already decoded string might lead to misinterpreting a percent data octet as the beginning of a percent-encoding, or vice versa in the case of percent-encoding an already percent-encoded string.

Clearly, if Internet Explorer (or any other web browser that supports this kind of protocol pass-through technique) were to encode characters that are not supposed to be in a URL, it would fall afoul of this definition in the usual case, by encoding "the same string more than once", once at preparation by a conformant URI provider, and once again as it passed through IE.

IE's best bet for compatibility and future extensibility (as well as compliance with current RFCs) is to not inspect or modify the scheme-specific component of any URI unless it is handling that URI itself.

Security Expert Chat - Thursday 6/21/2007, 4pm PDT

Alun Jones — Tue, 19 Jun 2007 18:52:00 GMT

Technet's brief description for a chat this Thursday (June 21st) at 4pm PDT:

Q&A with the Security MVP Experts
We invite you to attend an Q&A with the Microsoft Security MVPs. In this chat the MVP experts will answer your questions regarding online safety issues such as phishing, spyware, rootkits as well as server related topics. If you have questions on how to protect your PC, please bring them to this informative chat.

Here's a link to the calendar invite for those of you running Outlook, and on the day, at the time, you can click here to enter the chat room.

Why am I linking to it? Because I've been invited along as one of the "Security MVP Experts" - bring along your questions and concerns, and we'll try our very best to answer them.

For other Technet related chats, click here.

Couldn't have done that at Microsoft

Alun Jones — Thu, 22 Mar 2007 13:45:54 GMT

Today, another reminder of things I couldn't have done at Microsoft.

Last night, I rushed home from work in time to take my kid to his Webelos den meeting.

There, we worked on his Pinewood Derby car.

He's been sick most of last week and weekend, so he hasn't done as much work on it as he'd like.

So, I stayed up late last night, gluing parts together, and finishing up painting on spots he hadn't managed to get to.

I got up early this morning to finish the job.

And I even managed to put in some time on my own car.

I never could have done something so time-consuming while I worked at Microsoft.

Microsoft may be great for some, but I couldn't successfully maintain their lifestyle.

WIP: Principles of Secure Software Development

Alun Jones — Thu, 22 Mar 2007 00:19:00 GMT

This is a work-in-progress, but I'd like your opinions on it:

Principles of Secure Software Development

You're not that good - someone will find a hole in your software. Find as many as you can, first.
You're still not that good - you didn't find all the holes. Someone will find a hole in your software. Have a plan in place for when that happens. Pay someone to find holes.
[Corollary: If you aren't that good now, you weren't any better before, and you'll be just as bad in the future - so when someone finds a hole, scan for other similar behaviours in the rest of your code, and put processes into place that prevent you from making the same mistake in the future.]
Someone else is better (or has had more time to iron out the wrinkles) - if someone else has written it well already, use theirs. Make sure you keep up-to-date with fixes on it!
Even they are not that good - review and test for security threats in anyone else's software you use.
[Corollary: You were never that good, nor was anyone else, and you / they never will be. Re-visit old code with new understanding. Document new code as you write it and as you change it, and make sure it is simple enough to understand. Complex code has complex bugs that are hard to find.]
They wrote it for themselves, not for you - if you use someone else's software, review their assumptions and see if they still apply in your environment. [c.f. Rocky Horror Picture Show, "I didn't make him for you"]
Comments are not code (but code should read like comments) - use comments as a suggestion of how the code was supposed to run, and remember that code is often changed without updating comments. Make your code tell all the story it needs to.
If it's not your code, it's data, and data is evil until proven good - anything that you don't hard-code into the program is data. That includes mouse movements, window messages, network traffic, keyboard input, etc, etc. Anything that isn't in your source code should be treated as malicious until proven otherwise.
People are replaced easily, processes are not - ensure that your secure development processes revolve around processes, not personalities.
Secure development just plain takes longer - so make time for it. If you don't have time to do it right, when will you have time to make it right?
Secure code just plain works better - it's more reliable, has fewer bugs, is simpler to maintain. It may bring you to market slightly later, but a "second-to-market" product can beat a "first-to-market" product if it has an improved reputation for reliability.

So, let me know what you think of these - ten is a number picked rather arbitrarily, I could extend or reduce the list if you think I should.

Security Bulletins are easier to read in Japanese

Alun Jones — Mon, 19 Feb 2007 00:52:47 GMT

It's "Patch Tuesday" again - and you're going to be spending a busy Valentine's day installing all of them. I'm not the first person to cover this - Steve Riley did it way back when, and Susan Bradley reminded us of it, but it's time to raise the point up again.

You can get to the Japanese Security Bulletins at http://www.microsoft.com/japan/security/bulletins/default.mspx - there's a lot of Japanese script there, but it's easy to see where a particular bulletin - say MS07-005 - is, because those numbers are in a Latin character set.

Compare it against the English version of MS07-005. First, let's see how you get hit by an exploit against the vulnerability:

An attacker could try to exploit the vulnerability by creating a specially crafted message and sending the message to an affected system. The message could then cause the affected system to execute code.
There are several additional ways that an attacker could try to exploit this vulnerability. However, user interaction is required to exploit this vulnerability in each of these ways. Some examples follow:
•An attacker could exploit the vulnerability by constructing a malicious Step-by-Step Interactive Training bookmark file (a .cbo, cbl, or .cbm file) and then persuade the user to open the file.
•An attacker could send a malicious file as an attachment to a user through e-mail and then convince a user to open the attachment.
•An attacker could host a malicious Web site that is designed to exploit this vulnerability through Internet Explorer and then persuade a user to view the Web site.
•In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker could also try to compromise a Web site to have it deliver a Web page that contains malicious content to try to exploit this vulnerability. An attacker would have no way to force users to visit a Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's Web site or to a Web site that has been compromised by the attacker.

Did you understand that? I'm sure your management chain didn't.

How about in Japanese?

Okay, that's fairly obvious, the bad guy's web site infects your machine, or the bad guy's email infects it, either when you open the email, or open the attachments in the email. [The bad guy wears a black hat and dark glasses, of course.]

How about what can be done to your machine:

This is a remote code execution vulnerability. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Again, Japan makes it easy:

Oh, right, so the bad guy can drop a little copy of himself on my machine, he can look through his network "telescope" and see all my files, and he can reach through the network with his grabby thing, and dump my photos, files and emails in the trash.

ScreenSaverGracePeriod - how fast can you cross a training room?

Alun Jones — Fri, 26 Jan 2007 18:38:00 GMT

We're faced with an issue where presenters are losing their train of thought mid presentation because their slides are covered up by the screensaver - this would not be a significant problem, except that by the time they get back to wiggle the mouse, the workstation has been locked, and they have to type in their password again.

Clearly, we can't make presenters use a machine without workstation locking on the screensaver, or these machines would be accessible for hours under potentially "privileged" accounts. [Note that privilege includes social privilege here - if a VP is presenting, even if they're a restricted user in Windows, any email that comes from them is treated like the word of %deity.]

And I didn't want them finding their own solution (like the "Brandenberg Concerto" solution, where you simply play the Beethoven clip in Windows Media Player, put it on loop, mute the Media Player, and then minimise it), that might simply disable or prevent the screensaver completely, thus avoiding any chance of lockout.

So we found a really creative solution - ScreenSaverGracePeriod.

This is a registry setting - under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon - that controls how long you have after a screen saver goes active, to wiggle the mouse and get back to your presentation without encountering the workstation lock. [You've probably noticed already that you can wiggle the mouse quickly and not have to re-enter your password.]

It's only a little unfortunate that the documentation incorrectly describes this as a REG_DWORD setting - our own testing shows that it has to be a REG_SZ, even though the contents are a number, describing the number of seconds 'grace' you want. You can use decimal, or hexadecimal if preceded by "0x".

[Aside - why do Microsoft's programmers do this? Surely it's more effort to extract the string and convert it to a number, than have it stored as a number in the first place!]

Note that setting the ScreenSaverGracePeriod to 0 does not disable the workstation lock, it forces it to happen at any point the screensaver goes active, no matter how fast you are. The maximum value is 2,147,483 - seemingly a random number, until you realise that if you express it in thousandths of a second, it's the largest number that can be expressed in a four byte signed integer.

Trying to deploy an Outlook add-in

Alun Jones — Wed, 24 Jan 2007 06:36:21 GMT

Even us grizzled security professionals occasionally have to give up when faced with a pile of security so incomprehensibly bizarre as to make life seem impossible.

Recently, a member of our Security Council asked the simple question "instead of having us manually forward email to the junk mail filters, can we have a button that automatically forwards our currently selected messages as false negatives?"

When I heard of this, my natural inclination was "sure, I'm not doing anything terribly interesting or important with my few minutes of spare time a day - how hard could it be?"

I should slap myself every time I say "how hard could it be?" - although this phrase has often brought me my best achievements (WFTPD came from "this piece of crap FTP server [WinQVT/Net] crashes every time a second user logs on - how hard could it be to write a working FTP server?"), it's also brought on some of the hardest challenges. WFTPD took a solid six months before it was remotely usable, and a few years to get to its current state, including a three month period just trying to get SSL working.

In this case, of course, I said "how hard could it be - looks like it'll be really easy in .NET".

So, I spent two hours writing the add-in in C# .NET.

And the following three weeks trying to figure out how to deploy it.

There were pre-requisites and requirements, updates to install, KB article patches to fetch, and then I had to write or download an extra setup custom action to add my add-in to the Code Access Security using CASPOL.EXE.

Yuck. I mean, don't get me wrong, CASPOL's a wonderful idea - that you can list what behaviours a program is allowed to have, that's really powerful. Unfortunately, it's also difficult, and prone to making it so difficult that the whole project got canceled.

Fortunately, I'm not a one-trick pony. I canceled the .NET project, sure, but I got to looking at Microsoft's Outlook Junk Mail button - Steve Riley pointed it out recently - and I noticed that it's written as a straight COM component using C++.

So I do the same. It's slightly longer to develop - perhaps six hours, because I'm really not familiar with COM, and I make a few beginner mistakes. But to deploy - it's a simple case of copy the file, run regsvr32, and away we go - a perfectly operating (if possibly a little unsecure) Outlook add-in.

Can anyone tell me why I should have persevered with the .NET version?

Or better still, how I should have done it more easily?

Developers still don't get it.

Alun Jones — Thu, 11 Jan 2007 21:13:00 GMT

I'm perplexed by a statement made by one of the commentors on a recent Michael Howard blog posting.

Why would you NOT run [Visual Studio] as an administrator at all times?

As a developer, I spend enough time on my own work. I don't need to be spending ONE second switching profiles, typing passwords, or wondering when something fails whether it is a security issue or not.

I know many developers, and not a single person I know develops as non-admin. Since VS2005 needs to run as Admin, I'd be willing to bet that 99% of the Visual Studio team does the same thing too.

(and yes, I own (and read) Writing Secure Code, and I do keep a low-privilege account to test my apps, so I'm not *totally* ignorant about security issues)

Wow.

This emphasises a few things I've said on numerous occasions in the past:

Developers are prima donnas (you may have heard me use a different description, beginning with an "a", and ending in "rseholes"). I can say this because I am a developer, and I've spent a lot of my career in the company of developers. "I am not willing to spend ONE second ... wondering when something fails whether it is a security issue or not". Heads up, Bucky - it's your job, very specifically, your job, to spend a lot of time wondering how something will fail, and whether or not it's because of a security issue. If not the developer, then who? Tech support? What you get wrong in Development comes back a thousand fold to Tech Support.
Owning and reading "Writing Secure Code" is only the start. You actually have to get it. You have to live it and breathe it - and keep abreast of new issues that aren't covered in the book.
Testing security in to the product never works. It's too late by then, because the insecurity is already there, and it's good at hiding. All testing does is demonstrate that your testing was unable to find the holes.
Most code is never run by anyone other than the developer, until it gets to a few thousand users - as such, it always runs as administrator under its test environment, so it never fails until it reaches the user.
Developers are not administrators. Most of them don't even know what group policy is, let alone how to spell it. Even in a managed domain, developers' machines are segregated into their own OU, so that the developers can pretty much do whatever they want with "their" machines. As a result, unit tests are never run on machines that mimic production environments, even for in-house applications.
You can teach as much as you like, but some people just aren't that interested in learning.

Rather than asking for reasons why a developer shouldn't be an administrator, development team managers should be asking why a developer ever should be an administrator. Have an administrator account, perhaps, but almost all of a developer's work should be done as a local user, unless that developer is producing an administration tool designed only to be run by administrators.

[Nods go out to Susan Bradley and Dana Epps, who brought this article to my attention in the first place.]