Foresight Institute Logo
Image of nano

Security and nanotechnology

Three interesting articles appeared today on /. related to security which bear some thought when we think about nanotechnology.

The first involves the ChoicePoint Identity Theft problem. This involves perhaps 40,000 people in California and more than 110,000 people nationwide (in the U.S.) whose complete personal information has been lifted from an integrated identity database maintained by ChoicePoint. The scary part seems to be that they weren't checking their own customers with respect to their trustability — they were selling the information in the database to allow their customers to confirm that J.Q. Public could actually be trusted and weren't doing that themselves.

The second, involves good old Microsoft warning the the next generation of Windows spyware inserts itself into the kernel using "rootkits". This potentially effectively negates all normal virus scanning software. Its a case of the virus scanning software asking "Do you have any viruses installed here?" and the system responding, "No sir, absolutely not sir, we wouldn't even consider retaining spyware, malware, viruses or worms on this system, sir!" Microsoft has some proposed solutions — boot up a copy of windows from a CD-ROM and compare the binaries to make sure they exactly match the binaries on your hard drive. And of course that is likely to happen because as we all know everyone in the world is running with the most recent MS security patches installed…

And finally, there is the nice little comment about the T-Mobile web site that allowed one cracker (Nick Jacobsen) to log into the T-Mobile web site (details) and not only download lots of information about the secret service agents investigating him but he also managed to access Paris Hilton's account and some of the pictures she had been taking on her phone.

Oh I am predicting such a bright future for nanosecurity experts…

5 Responses to “Security and nanotechnology”

  1. RobertBradbury Says:

    Software vulnerabilities…

    Of course one of the more interesting comments in Computerworld was from Mike Danseglio of Microsoft's Security Solutions Group commenting on the rootkit authors, … "These people are smart. They're very smart."

    Given the quality level of many people that Microsoft hires, particularly one would expect with their current emphasis on security, this may be a very revealing statement.

  2. Chemisor Says:

    Re:Software vulnerabilities…

    You shouldn't be too quick to bash Microsoft's security experts. The code they have to work with is insecure because of the enormous mountains of old crud in it. This crud, a decade old, has been written by programmers who neither cared about security, nor had any idea that their common practices were ridden with holes. These days the current programmers are faced with a very challenging task of combing through those millions of lines to find potential vulnerabilities, with the concurrent requirement to preserve old functionality at all cost. Naturally, the two goals conflict, and in many cases the security problems may be simply impossible to fix without a complete rewrite that nobody will ever authorize.

  3. RobertBradbury Says:

    Re:Software vulnerabilities…

    I understand what you are saying but something as simple as buffer overflow exploits do *not* have backwards compatability problems and should never have been a problem.

    The first computers I ever used were DEC PDP-11s. They had a Harvard Architecture using what was known as I&D space. The first versions of UNIX were properly written to take advantage of the fact that you could load the code into I space, make it read only and you never had to worry about it getting overwritten by corrupted programs running amok. I will not lay all the blame for our current mess on Microsoft. I'm willing to allocate a fair amount to IBM for choosing the 8086 for the PC and Intel for throwing out 10-20 years of computer engineering experience when they designed the chip. If go back and look at computer history you will find that Microsoft did finally produce a decent operating system for the PC — it was called Windows NT which evolved into Windows 2000. But they had to hire Dave Cutler from DEC (who was a key player in the development of DEC's VMS OS) in order to get it right.

    There is plenty of blame to go around and no real excuse for the various problems. From a development standpoint we knew how to do things right when the mistakes were being made. Its simple sloppiness. The reason I brought these points up is that if we repeat the problems in the development of nanotech operations software that the evil triplet has managed over the last couple of decades we are going to have far far worse problems than we do now…

  4. Chemisor Says:

    Re:Software vulnerabilities…

    Fixing buffer overflows is not always trivial. If the code expects a fixed-size buffer, unintended consequences may result from switching to a dynamically allocated array. I've seen code that intentionally writes to the middle of the array before the beginning. It can, of course, all be fixed, but it takes time, and may introduce past-the-end references of a different kind.

    Finding the bug can also be quite difficult. Even the simple off-by-one index is not easy to spot, and most overflow problems are actually dependent on the data and how it affects the algorithm. It takes brains to ensure that the algorithm works as intended for every type of input. It's not sloppiness, as you say, but rather the lack of thoroughness, likely caused by the high-pressure deadlines so common in the industry.

    Your complaints about the x86 architecture allowing writes to the code segment are incorrect. Buffer overflow exploits do not write to the code segment, which is, indeed, read-only; they write to the stack segment and consequently jump to it. See this article for an example of how to do this. That the stack segment is executable, is not the flaw of the x86 architecture, but rather a deficiency in the operating system. It is perfectly possible to clear the execute bit on the segment, and there is a Linux kernel patch for it. Amusingly, it is not included in the mainline version because it would give a "false sense of security"; Linux hackers would rather fix the overflows. I don't know why Windows does not do it.

  5. JohnB Says:

    …gotta wear shades

    Robert stated, "Oh I am predicting such a bright future for nanosecurity experts… " I certainly hope so. There're only 3 real alternatives to this being true. One's a Bostrom-esque 'Scream' scenario, one's a malthusian solution, and the final one (and least likely, IMO) involves the tech never getting developed. Come to think of it, that first one's awful bright for nanosecurity experts, too, isn't it? Just not for most of the rest of humanity… -John

Leave a Reply