Innovation
Tuesday
Tuesday 28/1/2003What a mess! SQL Slammer hits the Net, triggers faults in Cisco routers, DNS falls off the edge of the world, ATMs clam up and servers break down.
Tuesday 28/1/2003
What a mess! SQL Slammer hits the Net, triggers faults in Cisco routers, DNS falls off the edge of the world, ATMs clam up and servers break down. It gets worse: the code that's exploited might be in SQL Server 2000 -- which people know to patch, even if MS has made it so difficult that nobody, not even in Microsoft, has bothered -- but the same stuff has ended up in a wide range of Microsoft and third party products. It's not the first time that a vulnerability in a library component has surfaced, meaning that anyone who's added a function to their program by plugging in an off-the-shelf component has also added a hole. Open source is just as vulnerable to this, of course, even if the chances of the problem getting noticed and a fix produced is higher -- and it has problems of its own. With commercial software, you can at least find out everyone who's got a licence to your code and contact them -- the first stage in getting the fix installed everywhere. With open source, though, you have no idea where the errant code fragment has ended up, nor if it's been modified or how. It could easily be that there's a chain whereby someone adopts a piece of code that was adapted by someone else who copied it from a third party, and that the person who produces the final piece of software has absolutely no idea what's in that chunk of the product. Even if you put out an alert in all the places that such people should read, it won't reach everywhere it should. The more I think about it, the more it seems that we'll have to bite the bullet and exploit the vulnerabilities ourselves, writing self-replicating, self-installing patches that copy themselves around the Net -- yep, our own worms. I'm not the first person to think this, not by a long way, and not the first to find the idea dangerous, unpleasant and very much against the rules. But it might be the only way -- and if done properly, it might work rather well.
What a mess! SQL Slammer hits the Net, triggers faults in Cisco routers, DNS falls off the edge of the world, ATMs clam up and servers break down. It gets worse: the code that's exploited might be in SQL Server 2000 -- which people know to patch, even if MS has made it so difficult that nobody, not even in Microsoft, has bothered -- but the same stuff has ended up in a wide range of Microsoft and third party products. It's not the first time that a vulnerability in a library component has surfaced, meaning that anyone who's added a function to their program by plugging in an off-the-shelf component has also added a hole. Open source is just as vulnerable to this, of course, even if the chances of the problem getting noticed and a fix produced is higher -- and it has problems of its own. With commercial software, you can at least find out everyone who's got a licence to your code and contact them -- the first stage in getting the fix installed everywhere. With open source, though, you have no idea where the errant code fragment has ended up, nor if it's been modified or how. It could easily be that there's a chain whereby someone adopts a piece of code that was adapted by someone else who copied it from a third party, and that the person who produces the final piece of software has absolutely no idea what's in that chunk of the product. Even if you put out an alert in all the places that such people should read, it won't reach everywhere it should. The more I think about it, the more it seems that we'll have to bite the bullet and exploit the vulnerabilities ourselves, writing self-replicating, self-installing patches that copy themselves around the Net -- yep, our own worms. I'm not the first person to think this, not by a long way, and not the first to find the idea dangerous, unpleasant and very much against the rules. But it might be the only way -- and if done properly, it might work rather well.