more alerts on Y2K Kiddiesgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
http://www.hackernews.com/arch.html?011000#4 re buffer overflow controversy.
My Houston colleague will not post again out of respect, so I will offer this reference. Buffer overflow as a hacking window has merited much attention of late. I respectfully suggest that the "crackers" may be the real Y2K. Forgive me if I speak out of turn , but I believe that the "party is just beginning".
-- charlie in houston (email@example.com), January 10, 2000
-- Huh? (Not@Geek.com), January 10, 2000.
Gee, took the words right out of my mouth. Huh?
-- Richard (Astral-Acres@webtv.net), January 10, 2000.
Charli suggests that perhaps the real Y2k events will come from the hackers and their recently publicized "buffer overflow" hacking methods.
If curious, check out the link.
-- Cin (Cinlooo@aol.com), January 10, 2000.
The link took me a few steps away from this article which I found very interesting: "A New Era" http://www.hackernews.com/bufferoverflow/00/newera.html
I would like to hear what other people think about the author's premise (that reliability of software will take priority over functionality). If so, what's a businessman to do? How can he choose robust operating systems or Office Suites if the rest of world is exchanging files created by systems that rely on end users discovering bugs?
Go one step higher and think of the government's developing interest in "infrastructure protection." What requirements in the software development process could be imposed legislatively? In all government contracts? Specified by standards setting bodies? In other words, if this shift in perspective were to occur, how might it play out?
-- Jay Golter (JGolter@aol.com), January 11, 2000.
It looks like it may be a marriage of Y2K effects and opportunistic hackers. A Y2K effect on some systems is a buffer overflow situation, and a computer sysem experiencing a buffer overflow presents an opening for the hackers to get into that system.
Of course if a buffer overflow situation is bad enough itself, the results might be mistaken for a malicious hacker attack. And then the excuse would be "See! It wasn't Y2K. It was cyberterrorist hackers."
-- Wildweasel (firstname.lastname@example.org), January 11, 2000.
Hi Jay; Microsoft has always "depended on end users finding bugs" perhaps not deliberatly but it still has done that. This is true because the author's initial premis that software has been historically developed for functionality first is also true. "Just get it written, make it work, and get it out the door." That has always been the way the system drove the programmers.
His suggestion that we go for reliability vice functionality as a first prerequisite is reasonable. He presents the idea that this will be come increasingly important as more networking is done is valid because putting a machine on the network is stepping into a new neighboorhood. When you have no presence on the network, you are not exposed to the folks who would "kick your door in" or "pick your lock" to get at your valuables. The degree of presence you have on the network is a constant that drives the exposure you have to these folks. If your machine is connected 24/7 you are exposed 24/7... If you are a dial-up user online for a hour per day you are exposed (1/24)/7 or one twentyfourth as badly.
Reliability/security will become more important as more people remain connected 24/7. Unless you have sat at the keyboard of a machine which you knew for a certainty had been compormised it is hard to imagine what it feels like. It makes everything else moot.
You sit down and login as the administrator. You know that your keystrokes may be monitored and you know that your screen may be being read by the intruder. He owns the system. You hope he is not watching at the moment and begin searching the system for evidence of his activity. "Ah hah!, what is this file in /usr/games/.../dump.dat?" You compress the file and begin dumping it to a different machine you set up to be secure. Moments later the dump abends and you go back to the file to find out what happened but the file is gone... You check the file on the download machine and find you got most of it, so you recover what of it you can and discover that it contains a sniffer log and that the administrator password for the new machine (the download secure machine) is one of the items in that dump file. You slap yourself several times for not following proper proceedure and discipline because you KNEW you should not have trusted the network and logged into the secure machine from the network. You knew the network might have been compromised.
You immediatly disconnect the secure machine from the network and start the audit on it hoping that he has not already gotten into it. You find you were lucky. You have now established that the cracker probably owns every other machine on the inhouse network because you know the administrators frequently telnet from one machine to another. He owns the router, the portmasters, every single piece of hardware that comprises the internal network.
That is the beginning... the first hour or two. Now the fun begins. There are 2000 users dialing in on 200 lines. Your customer absolutly can not afford to have his entire network taken down and you know that he no longer owns his network. You are completely at the mercy of the cracker -- piss him off... well... you get the idea. If you are truly lucky you discover that he is a professional cracker, that he is doing it for the money and has a vested interest in keeping the system running. If you are truly unlucky you discover that the cracker simply is doing it for the fun of it. The real frustration is the customers reaction... He doesn't understand what a sniffer is, how it works, what sort of information it collects. He doesn't understand how badly he has been compromised. Worst of all he doesn't realize how exposed his customers have become... That is the end of the first day.
You urge him to call around and contact a state or federal agency. Finally he does. They tell him they really appreciate any information he can provide to them... you dig thru the download you took yesterday (it's only 40 megs or so) discover the credit card numbers that were compromised, discover the accounts on other systems that were compromised, use all of that to leverage interest from the agency. They hire a consultant because they don't have the inhouse expertise to do the job themselves. He's the "pro from dover". He comes in like a real hotshot and promptly does stupid. He sends you messages across the compromised network... What are they paying this fool anyway? How can I get a piece of that, I see already that I am going to get no real help here. That is the end of the second or third week because it took a week or ten days to set it all up in the first place. You have now established that you are going to have to do this yourself. You have establised that .gov is brain dead when it comes to this level of expertise and you know that .mil has no legal interest in such matters.
For the next two months you study this fellow (these fellows) to figure out what they are doing, why they are doing it and how to inconvience them enough that they will go away. BECAUSE THE OWNER WON'T LET YOU UPGRADE HIS SYSTEMS FOR FEAR IT WILL DISRUPT THE CUSTOMER BASE.
Eventually you have the systems stripped down to what they should have been installed as in the first place. Now they basically do nothing but, can't do anything but, what their primary purpose is in the first place. The only thing left is the mail server. They are using it for spamming and advertising...
One day you finally get the chance. You upgrade all the systems and the cycle starts anew because for every fix there is a counter, for every patch there is a crack...
Yeah, reliability/security will become the overriding issue in the next five years.
-- Michael Erskine (Osiris@urbanna.net), January 11, 2000.