Extract From Byte Magazine - Nov 26 - Flashback

[Steve Bildermann]

As Byte is now a subscription service I thought some people might enjoy reading some extracts.

SQL Injection Attacks

One of the Microsoft Professional Developers Conference sessions was on known security vulnerabilities, not just in Microsoft products, but across the computer world. All of those shown have been found and in theory eliminated, but some of them were frightening.

As an example, they showed a SQL database dummied from a real one. This one held book reviews and ratings. With a few operations they were able to show us how all the ratings for books by particular authors could be inflated, and words like "not recommended" turned into recommendations; while rival works were given bad reviews. All this was done from outside the data base by SQL injection attacks. Most of those holes were generated by buffer overflows; more on those later. <continued>

[Steve Bildermann]

But entire databases can be copied, or altered, or both; and once again the commercial incentives for attacks like that are quite high. These aren't just hacks for self esteem any longer.

The Insecure Future?

Years ago I wrote about a future in which everything was smart and it was all connected together. I mused that your refrigerator would natter with your toaster about your bank balance, and your new car might telephone you at the supermarket to ask if you really wanted to buy that expensive wine given that the car payment was due and your bank balance was low.

That's all happening now. You can buy a refrigerator with an IP address. UPS systems have long had IP addresses. Smarter VCRs and DVD players have embedded computing systems. TiVo and Replay devices have or can be given Internet access in order to update their program guides.

ITRON

The operating system in most of these devices is ITRON, which may be the most widely used operating system in the world even though most people have never heard of it. TRON, The Real time Operating system Nucleus (of which ITRON is a sub project), is a family of real time embedded operating systems that have been around for almost 20 years; everything from cellphones to stereo components to microwave ovens runs one of the TRONs, and while embedded Linux is making great strides, ITRON and its cousins still hold the lion's share of the market.

TRON was devised in Japan by a consortium of companies, and has been implemented on many different 8 , 16 and 32 bit processors. To their credit, one working group is about to release the "IIMP kernel," which appears to add considerable protection and security, but it's only now hitting the specification stage. No one really knows how vulnerable ITRON may be to various hacks.

So what? What do I care if someone can reprogram my refrigerator? Or my VCR for that matter. They can annoy me, but they can't really hurt me

Or can they? Certainly restaurant owners, biology laboratories, and blood banks have reason to worry about their refrigerators, and anyone with a server on a UPS would be reluctant to give control of that UPS to a hostile outsider. And that's now: things are getting connected, but they aren't all that smart yet. How long before they are all smart and interconnected? And vulnerable.

Now that we're seeing cellphones and stereo components and microwave ovens with Ethernet ports and IP addresses, just how sure are we that they can't be exploited by miscreants to wreak havoc out here in the real world? As recent events have shown, it's pretty easy to use hardware for purposes other than that for which it was purchased; how many back doors and buffer overflows are out there waiting to be exploited in the various embedded systems we rely upon every day? As more and more of these systems are provided with network connections and the capability to be remotely updated all in the name of convenience how soon will it be before we have a Windows worm which scans for, say, Linksys routers, updating their firmware with special code which "phones home" and reports all the credit card and other private information which passes through them, not to mention serving as DDoS zombies for the odd Internet extortion attempt?

The law of unintended consequences, coupled with poor design choices, may yet be our undoing.

More Hacks

Belkin, a company whose peripherals I often recommend, recently got into the router business, and for some reason allowed their marketing people to build spamming capabilities into the routers. Every few hours the router would grab a random HTML connection and direct it to Belkin's advertising page. See here or here for the details.

Think through the implications of this.

Here's another scenario. You get an odd glitch in your system, and call tech support for your router. You are connected to technicians in India or some other overseas area; outsourcing tech support to overseas areas is becoming quite common. The technician tells you to download this flash update for your router's firmware, and tells you how to install it. The technician has been compromised: is an agent of al Qaeda, or is being blackmailed or intimidated by one or another such organization. I needn't tell you that once your router has accepted a back door the rest of your network isn't very safe. You now own a zombie that can be directed to attack any installation in the United States. There's a novel in that, and I may yet write it.

We are, I think, building a security nightmare. Until recently we have relied on security through obscurity, or through inaccessibility. Now there's little that's obscure to someone who wants to find about it, and we are deliberately making everything accessible.

As to the supposed impossibility that some bright young person from a third world culture might go to a good technical institute either in India or the West, and graduate hating the West and all its pomps and works, think on Alger Hiss, or Kim Philby, who had all the benefits the West could confer and yet chose to join a conspiracy dedicated to bringing down the whole of Western civilization: a conspiracy that at the end of the Cold War had some 26,000 nuclear weapons targeted and ready to launch. If English and American upper class kids could be persuaded to join the Communists, why is it unrealistic to think the same could happen to privileged kids from the third world?

Security, and Service Pack 2 for Windows XP

One session at PDC was on the upcoming Service Pack 2 for Windows XP. It was so popular that it was repeated along with a closely related security panel.

This isn't a full report on those sessions. If you are at all interested I urge you to go to MSDN and read it all.

The bulk of the session was about security measures that will be incorporated in SP2, and how a number of bugs can be fixed. The most common exploit involves buffer overflows. (For an odd but informative presentation on just what this is, see http://www.cultdeadcow.com/cDc_files/cDc 351/ and prepare to be irritated.)

Buffer overflow involves filling an input buffer with more information than it can hold, then including at the end a means of directing the computer to issue itself instructions of your own. This sounds complex and is; unfortunately, some highly gifted crackers have generated scripts uasable by the malicious but non gifted. The scripts will generate buffer overflow exploits to give the script kiddies control of machines even though they don't really understand how they work.

After about half an hour of explanations on how buffer overflow exploits work, a light dawned, and during the break I went up to talk to the experts. "Wouldn't all this be prevented if the compiler did strong type checking and range checking at compilation?" I asked.

The answer was long but essentially "Yes."

The Language Wars

Twenty years ago we had the language wars in small computing. They raged on in BYTE and Dr. Dobb's Journal and other magazines seriously devoted to small computers, even if they were largely ignored by the old line "big iron" computing journals.

On one side were computer scientists like Niklaus Wirth of ETH in Zurich. They advocated strongly typed languages and range checking, and they insisted that their compilers be recursive: The compiler would compile itself in its own language. The compilers were very picky, and you had to be careful what you told them lest they issue compile time errors; but once the program was compiled, and the program would run at all, you had good reason to believe that it was doing pretty much what you had intended that it would do; and exploits like buffer overflow were simply impossible since input lengths out of range would not be accepted and you couldn't compile the program if you didn't specify the acceptable size.

On the other side were advocates of the language known as C. They were led by Kernighan and Ritchie and Plauger, and they advocated the C family of languages. C was more assembler than computer language, and the C compiler would compile almost anything, including nonsense like sending off data of one type say an integer and having it return as another data type such as a floating point number. Worse, it could and did confuse data with program instructions and it was up to the programmer to simulate the compiler in his head as he wrote the code, so that he wouldn't send the program into a data stack looking for instructions. Perhaps I exaggerate, but not much.

The language debates were heavy for a while. Artificial Intelligence experts like Marvin Minsky sided with the C people (although they used languages like LISP and APL for their work). Minsky once accused me of wanting to make programmers put on straightjackets before they could write code. The watchword was freedom! In the jokes about shooting yourself in the foot, the line for Pascal (Wirth's strongly typed, range checked teaching language) was "Pascal won't let you shoot yourself in the foot," and the C programmer's answer was "Sometimes systems programmers have to be able to shoot themselves in the foot!"

Of course that's nonsense. Nobody really and truly wants to shoot himself in the foot or incorporate dangerous vulnerabilities in systems code, and if you think you have to do that, you have not properly thought out what you are trying to do.

C won out as the systems programming language of choice, despite its obscurity (you still have to simulate the compiler in your head when you write C code; the compiler won't catch quite a number of easily made but very serious errors of the type change and out of range variety); and despite its near unreadability (it is notoriously true that an incoming code manager often finds it easier to rewrite from scratch than to understand his predecessor's C code). I say despite, but perhaps I should be saying "because"; C is also known as the guru programmers' employment insurance language.

C won largely because the hardware during the critical period of the language wars was slow and clunky, and C would compile fast minutes to hours rather than hours to days on big programs and generated code that ran significantly faster than programs written in Pascal, Modula, and Oberon.

In fact that latter isn't true: structured program languages might generate slower run time code, but they also indicated how you could improve run time performance by hand optimizing critical code loops and such. Mostly the speed advantages of C were in the code writing phase of a project. On the other hand, it could sometimes take longer to debug a C program than to write it and get it out the door using Pascal and its successors. Structured languages made you think you did have to wear the straightjacket and program planning took a lot longer but once you had the structure set right, the actual code writing was comparatively quick.

I see that I'm fighting the language wars again, and that isn't quite my purpose just now. Just say that C won because it was faster back in the days when 20 percent faster might mean hours, not a few seconds.

Type and Range Checking

My point was that if Windows XP had been written in a language in the Pascal/Modula tradition, rather than in the C tradition, there would have been strong type and range checking, and buffer overflow exploits would be impossible.

Interestingly, there was considerable agreement (with quibbles; I don't want to misrepresent anyone). But, I was told, there are range and type checking compiler switches in C#, and one of the fixes proposed for SP 2 of Windows XP is to recompile large chunks of the code with those switches turned on.

Shout Hallelujah! said I. Then came discussion. The problem, one senior Microsoft executive said, was that if they weren't careful they would end up with a Service Pack larger than the original code distribution. For some reason he thought that would be a Bad Thing.

XP SP 2

I have been thinking about that ever since, and he's wrong. Replacing every line of Windows XP with more secure code would be a Good Thing, and it wouldn't be expensive. It would save Microsoft money in the long run.

The distribution cost increment comes from needing more servers, particularly when the Service Pack first comes out. The cost of storing 600 MB isn't all that larger than the cost of storing 40, but if a lot of people want it at once, you will need more servers doling out the code.

Otherwise the costs are pretty trivial. On the user side, sure, it takes longer to download 600 MB than it takes to download 40, but the return is well worth it; and of course you aren't going to download either if you don't have a high speed Internet connection. If you're on dial up you're going to order the disk, and it certainly costs little more to fill that CD than to ship it mostly empty.

I am convinced, and I am persuaded that many of the Microsoft gurus are convinced, that many of the XP security flaws will go away when the code is recompiled with proper range and type checking enabled. Of course there will be programming issues: You have to generate code to handle what happens when an illegal type change or out of range error is detected; but again those costs are small compared to what happens when SoBig or SQL Slammer hit the Internet.

I hope Microsoft will see it this way.

And I can't resist saying it: I told you so. Here. At BYTE. Twenty years ago.

[Big Booger]

Great article. Thanks yet again Steve. One thing I don't get, is if the C code could be compiled with these range and type check switches turned on, why in the hell did it take till XP SP2 to compile it with it turned on, considering the speed of even last years hardware?????

I am sure that it would have saved us all from a lot of trouble.. It sure would have helped sys admins with the blaster worm It wouldn't have even been a bleep on the radar screen IMHO.

I can't wait for SP2 as long as they don't include any crap that limits what I can and cannot store, change, edit, or modify on my PC>