Tales from the Crypto

Random leap-day events.

A semi-hobby of mine is that of date- and time-related issues with computers. Something that we all take for granted, and assume to be easy, is actually incredibly complex, with rules that depend on where you are, when you are, which laws you follow, which religion you believe in, and any number of other steps.

I knew there'd be one or two events for leap day to comment on - here's a selection for your amusement:

"Software Snafu delays United's Leap Day check-ins" - a spokesman "says United didn't have any such problems with the software on Leap Day four years ago." - not much thought given, I suppose, as to whether there might have been an update or patch in those four years.

Microsoft's SQL Server 2008 - two days after the product launch in Los Angeles:

“We have recently discovered an issue with SQL Server 2008 CTPs that result
in SQL Server 2008 not starting on Feb 29 GMT only. We recommend that you do
not run or install this CTP on Feb 29 GMT to minimize any impact in your
environment. You can install starting on March 1 GMT. If you have already
encountered issues, contact sqlbeta@microsoft.com before taking any further
steps.”

Microsoft's Windows Small Business Server can't issue itself a certificate today, because when it creates the certificate, it makes it valid until today's date, five years from now. That would be 2/29/2013, which isn't a valid date. Splat.

South Carolina's DMV brought down because of "a bug in one of the programs that calculates the date".

Electronic Arts give their employees a day off for Leap Day - I was going to make some weak joke about "an EA spokesman said that as the following day was a Saturday, they expected everyone in the office as normal" - but then I read the spokesman's comments from the article: “The next leap year isn't until 2012, but the company is trying to come with a reason to give its employees another day off in 2009.” So there you are, if you work at EA, you get another day off work next year. Write down family members' names and addresses so you can contact them again when next you get to leave the office and go out into the "big blue room".

CS-RCS Pro on Vista

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

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

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

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

Here's the sequence I have to deal with:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dealing in Vulnerabilities - Denying the Vendor

Full disclosure, responsible disclosure, malicious exploit use, there are so many ways to act when you find a vulnerability.

What about disclosure to a select band of people (selected only by their ability to pay you a bucket of money every year), and demonstrating the vulnerability publicly, while simultaneously withholding details of the vulnerability from the vendor in whose product you found the hole?

That's what Russian Security research company Gleg is doing right now with RealNetworks, according to an Analysis piece in this week's eWeek (sorry, eWeek, I'd link to the article, but I couldn't find it online).

The researchers at Gleg found a vulnerability that allows them to execute their choice of code on any system whose user they can convince to play a song in RealPlayer - and there's not a lot of convincing that needs to go on.

RealNetworks have contacted Gleg and requested, on a number of occasions, to receive details of the vulnerability. Gleg refuses. Repeatedly.

Why?

"We need an exclusive time period to protect our customers..." and "We tried to work with vendors in the past and received a very negative experience."

If this "negative experience" is the usual complaint of vulnerability researchers, it is that vendors are non-responsive when vulnerabilities are reported - clearly in this case, that's not true. RealNetworks are asking Gleg to allow them to respond to the vulnerability.

Subscriptions to vulnerability researchers' "services" already seem rather like a protection racket - "pay us every month, so we can tell you how to prevent your systems from being exploited by something that we found".

With this refusal to disclose to the vendor without them becoming a customer first, this seems more like blackmail.

As Dave Aitel of Immunity states, for RealNetworks to subscribe to Gleg's service might very well be "a drop in the bucket for them", but consider that it's Gleg that discovered this vuln, it might be Immunity for the next vuln, you can't predict who's going to find the next vulnerability in your software. A few drops and you've overflowed your bucket. [For those of us vendors with a thimble-sized bucket, a single such drop is going to be too much.] How do you go to the CFO and ask for more money because there's another dozen security research companies starting up this month? How do you classify the return on investment?

Oh yeah, Immunity... "Immunity does not share its findings with affected vendors" either, according to the article.

I understand that security researchers have to feed their families, but there has to be a better way than protection rackets and blackmail.

I've often stated that I got into security because I wanted in some small way to help save the world - I don't like people who are apparently in this business solely to make money, and with no interest for improving the world around them. It's a short step from there to developing malware for pay.

Update: Just to prove I'm not making this one up (eWeek, where's that article online?), the story is also reported at DaniWeb.

MMR vs Autism - Amateur Epidemiology

Once again, the headlines declare, "No link between autism and MMR vaccine".

The story, however, is a different matter:

The study, published on Tuesday in the Archives of Disease in Childhood, found no evidence of any abnormal biological response from the shot that could point to a link between the vaccine and autism.

Hmm... an absence of evidence of a link does not mean evidence of the absence of a link.

"This study really supports the view these are safe vaccines," said David Brown, a researcher at Britain's Health Protection Agency who worked on the study. "The evidence is now so solid there really isn't a need for further studies here."

Same old guff that's been said at the conclusion of a number of other studies, all of whom appear almost deliberately to have been set up to provide statistics that imply the absence of a link. Perhaps the most famous is the "Danish study". The study demonstrated that there was actually a higher risk of autism among those who did not receive the MMR. What was not noted in that study is that it occurred at a time when the suggestion of an MMR / autism connection was big news, so those children already at risk of autism were more likely to turn up in the group of children whose parents refused to give their children MMR. A self-selecting study is no study at all.

As Jackie Fletcher of JABS puts it:

It is making a leap from having the actual data on the antibodies and saying MMR does not cause autism.

Persistent measles infection is only one of the theories on why there appears to be a connection between the MMR vaccination and autism - my favourite explanation by far is that there are children at risk from autism, and that every time their bodies are put under significant stress (such as the high fevers associated with vaccination), there is a chance that a regression will be triggered. That's a very loose theory, granted, but there are others - one very interesting suggestion is that the study quoted in today's news articles focuses on children aged 10 - 12, and if those children had persistent measles infection from vaccination at or around 2 years old, it would not be evident from antibodies in the bloodstream, but in the spinal column. I don't know how true that claim is, though.

Now, you might say that the studies that have suggested a link between MMR and autism are also biased in their construction, and designed to give the results that would imply such a link.

I agree.

An appropriate study, in my opinion, would be to select candidates who are "at risk" from autism - where a member of the family has autism, or where a member of the family is an engineer, or where there is higher-than-average incidence of college education - and follow their babies from birth through age five or so. Some of the group would be given the MMR in one visit, as is the current method of operation, others would be given separate Measles, Mumps and Rubella shots in three visits, several weeks apart. A little tricky to do this as a double-blind study, but not impossible - the MMR patients would simply receive a saline shot instead for two of their three visits.

Such a study would get over the issue that, with an incidence rate of 1 in 150, and only a fraction of that being suggested as related to MMR vaccination, autism causes disappear into statistical noise; such a study also allows for possible weighting factors to be recognised and balanced (by assigning study members such that particular combinations of weighting factors appear more or less equally in each cohort), in a way that has not been possible, or not been tried, with other studies.

While there are many irrational views on both sides of this debate, sadly it seems as though these are the views that make the loudest noise.

A scientific approach to this discussion has not yet been considered, in my opinion.

Most parents of autistic and at-risk children I have spoken to (and granted, that's not in the hundreds that would be required for a good sample) are not looking to make the choice between MMR or not vaccinating their children - they are artificially limited by the government to making that choice. The lack of availability of individual vaccines for Measles, Mumps and Rubella makes the choice one of "MMR and possible-to-likely autistic regression" versus "possible measles, mumps or rubella infection - maybe in someone else's kid". I think that particularly when it comes to illnesses like Rubella, where the risk is to the in-utero fetus of an infected mother-to-be, perhaps we ought to consider whether it is safer to vaccinate girls as they approach their fertile years, rather than vaccinating everyone a year or two after birth, in an attempt to provide "herd immunity".

Another thing I'm not looking for is to blame all (or even most!) cases of autism on the MMR vaccine, or thimerosal, or any of a number of other causes. There are so many stories of autistic onset, from the kid who "everyone could see he was different from the moment he was born", to the kid who develops normally into a babbling toddler and then suddenly shuts up and retreats into his mental cocoon over the course of a few days. Clearly, there's a genetic component that at least creates a susceptibility, but for something to happen so suddenly, and so coincidentally "on time", it seems like there has to be an environmental component that acts like a trigger.

With the government continually feeding us crap science, and no physical method to reliably screen for a majority of autism cases, it's no wonder many parents feel like emulating their children at their worst autistic moments, repeatedly banging our heads against the wall, because it's better than not knowing why our heads hurt.

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

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.