Slashdot Mirror
CERT And Vulnerability Disclosure
Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net.
The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."
No, this is typical of someone who likes the fact that fixes for known security problems on my os are within 24 hours, and not weeks. I have to us MS, and help people use it and I hate every aspect of it. I don't hate it because I like unix, I hate it because it's shit, and anything that hurts MS is a step towards me not having to deal with it anymore.
This is a MS world right now - I don't have to like it.
The users/customers need to know of vulnerabilities. They do NOT need the actual exploit tools. Publishing the vulnerability is one thing, providing a tool that actually exploits the vulnerability helps no one but script-kiddies. THEY are the idiots who are likely to actually download the exploit and then immediately use it to do their little, pointless, damage.
What possible good does it do to give script-kiddies the tools they need to bust systems that, otherwise, they are too stupid to be able to figure out themselves?
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
Now that CERT is saying to the vendors, "look, 45 days is enough to do something, just feeping do it", I hope that corporate buyers will start demanding real action on structural issues. Take the LoveLetter "virus": if a significant number of buyers would tell Microsoft that they should address the issue of hiding important information from the users so that they could make an informed decision on whether or not to open a certain e-mail message, Microsoft might address the underlying issue and fix it once and for all: not just the e-mail case, but also shared file stores and web sites.
Sigh. It has surprised me from the outset that there hasn't been a buyers uprising. People overestimate Microsoft's Evil Empire nature and underestimate the delinquence on the part of users to make their concerns known.
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Exploits are needed because they are a way of describing the security hole in a manner that directly shows exactly what information damage and/or theft can occur. They also often point to ways that a specific security hole can be avoided or closed up before the company in question releases a patch.
The -problem- with exploits is that they are often too narrow minded. They may take advantage of a hole that is much bigger than the exploit itself indicates...leading to people thinking that if they stop the particular exploit, the hole itself is fixed.
While all of you are discussing the ideological and legal aspects of this, I think I would like to address the practical side.
Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus, out of ignorance or lack of time. However, the Internet is crawling with 5kr1p+ k1dd135 who do, and they have preyed on our system. I do not appreciate the abstract, idealistic attitude of this community, the good-ol-boy mentality that if you aren't an expert administrator, you ought to be hacked by 14 year old malcontents. They used that goddamn wu_ftpd exploit on us and we had to reformat and waste another freaking day reinstalling and upgrading the only OS I've ever personally seen hacked.
Now RedHat wasn't the only distro affected by this exploit; this is truly an open-source security problem. Consumers will not latch onto Linux if it's this hard to keep secure. There are several items your community needs to address:
You might not care if all the "dumb" users go away, but you know what? Then your OS won't win, you will always be stuck in nerd obscurity, and MacOSX will be the #1 unix in the world.
a prophet on the burning shore
CERT has had a history of releasing vague reports about a problem fearinf that embarassing the vendor was a bad idea. IMHO, the more embarassed, the better.
I don't think exploits should be released right off, but upon discovering a security hole, you should immediately release a detailed enough description that an exploit could be written by someone competent in a few days.
Releasing an exploit is something you do after you feel the bug has been out for long enough for someone to have coded one anyway. I would say, 3-6 months after the bug has been disclosed, but probably not at all if the vendor has a patch. This gives vendors enough time to code a patch, but doesn't let them ignore you.
I don't think there is anything about actually releasing the exploit immediately that should be actionable under the law. It should just be considered rude and in poor taste.
That's my personal philosophy, and IMHO, what CERT is doing doesn't go far enough. I don't consider releasing an exploit as necessary to claiming full disclosure. I do consider immediately releasing all pertinenet information to be required.
Need a Python, C++, Unix, Linux develop
You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
Testing whether or not your particular setup is vulnerable or not sounds like a pretty "LEGITIMATE" use of an exploit to me. I shouldn't have to understand every possible security problem in depth and write my own test exploit just to determine whether I'm vulnerable.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
.. :-)
I as an admin have legitimate use for it. I'm able to run the exploit against my box, to check if I'm vulnerable. If its a proper description of the vulnerability in addition,i'll be able to check if the flaw is there at all in my version of the software.
Exploits is an easy was to check if you're vulnerable and needs a patch. Its helluva lot easier than to check if you've got the updated libs, and if the program is updated, and versionchecking everything.
Of course, its not foolproof. You may be vulnerable even if the exploit doesn't work. But, if you run redhat, and the exploit is for redhat, then
Furthermore, you say that full disclosure is the way to go. And right afterwards, you say that exploits shouldn't be released. Sorry mac, its not full disclosure if you don't disclose everything. You seem to have misunderstood something.
For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it!
And how exaclty do you know that? When l0pht released the informatiom, security minded people were able to patch their systems, because they forced a fix to be made. If they had not publicised the information, you wouldn't know about it. You wouldn't know that you were vulnerable, and if you had a smartass cracker around, he could run circles around you without you understanding what the fsck were going on.
You seem like a troll, but are modded to 5.. I don't get it.
The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
And how can you be so certain about this? You really can't. What is unknown is unknown. You are doing nothing but theorizing right now.
Btw, as far as I know, slashdot has been cracked once without anyone having any idea on how it was cracked. Furthermore, rootshell.com was cracked about 1-2 years ago. I don't think they've discovered how yet. So, you are saying that the superhackers don't exist, even so, we see this kind of things.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.
I seem to remember som corporations using more than a year in patching some holes. I think they are my enemies, not the scriptkiddies. And I've been cracked by scriptkiddies. If the tools weren't widely published and available, I would never've known what hit me. (maybe i wouldn't have been hit, but that i can't know).
--
"Rune Kristian Viken" - http://www.nwo.no - arca
Funny, I got an ILOVEYOU just a few days ago but
I guess they fixed it by now...
L0phtcrack wasn't the first program to crack lanman packets. It was the first that combined all the known ideas into one package easy enough for a scriptkiddie to use.
Publishing exploits also expands the knowlege base of how typical exploits work.
15 years ago most programers would not believe that you can write a program that overflows the buffer of a second program causing it to do something uninteded other than dumping core. Now people understand buffer overflows are a real issue but only because of the huge library of exploits.
No, his manager is doing the right thing. Mr. Security Administrator needs the right information to tell Mr. Important Executive exactly what's at risk and what the cost is, and whether immediately running around patching all possible servers is the only way to prudently reduce the risk (versus, say, doing something else, like watching very carefully).
Without full disclosure, Mr. Security Administrator can't possibly do this. He's reduced to saying "fix everything immediately because CERT says so". This is not a real convincing argument in a world where you have to justify costs and benefits.
If your children ever found out how lame you are, they'd murder you in your sleep
But they don't.. even then. If someone gets owned they immediately blame the purpotrator (and rightly so) and usually have very little vengence left over for the software company. Most software consumers beleive that "hackers" or "crackers" or whatever you want to call them, make the bugs in software, not the software makers.
How we know is more important than what we know.
Also a decent software provider can't release a patch without THOROUGHLY testing it first.
M$ did that kind of stupidities many times as an example...
I don't see as the exploits are needed. Sure, they should release them to those responsible for fixing the software, but there's no need to release them to the general public.
I would have to agree with this. Further more, by publishing exploits to the general public, you are just giving script kiddies the tools to break into something. Why make it easier for them to break into machines. If they are gonna do it, at least make them code up the exploits themselves. And hey, who knows. That young kid who right now is wipping some exploit up might grow up and turn into a serious responsible kernel hacker.
So this isn't a "complete embrace of full disclosure" huh? What exactly do you want? Possibly CERT should crack the app or site for you and hand you the root password as proof?
Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
I am always irritated by people who make flip remarks like "security through obscurity is proven not to work", when the basis for their remarks is that some vendors didn't patch known vulnerabilities in the days when STO was more prevalent. In reality, the aim of information security is NOT to eliminate all security holes. The aim is to prevent legitimate users from service interruptions and abuses. It's not that difficult a distinction, guys. For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it! The theory of some full disclosure zealots is that if all vulnerabilities aren't released and coded up within 24 hours of discovery, some shadowy breed of "super hackers" out there will find it in time and exploit it. Guess what - these super hackers DON'T EXIST. The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
CERT has it right. Disclose the vulnerability to the vendor. Give them A LOT of time to fix it, and a lot of goodwill. Software companies can be slow on their feet - they can't address every problem that crops up in the 12 hours you give them until you announce "they haven't responded". But if the problem is not patched in that liberal amount of time (45 days seems enough to me) THEN feel free to shout from the rooftops and embarrass the suckers.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users. For some reason it is easy to lose sight of that fact in the world of infosec, where everybody believes they are unusually smart and the companies they correspond with unusually stubborn. I know - I work in that field and ego is a dangerous thing. Don't let it blind you to what should be your real goal - helping people improve their lives.
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
hey, if your manager sucks that's a problem by itself
there's no way you can blame CERT for that
When I read "will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix", I took that to mean that they would never provide full disclosure before 45 days. Not true at all, they will provide dislosure within 45 days. Big difference. Also (pet peeve, but I wouldn't post if only for this), you spelled "its" wrong.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
Let me first say that, in general, I welcome this change to CERT policies. CERT announcements have become increasingly less relevant as the bugtraq list has grown and as the SecurityFocus team has added better tools for tracking and researching vulnerabilities. One interpretation of this change is that it represents a desperate cry for relevance by the CERT folx.
Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.
An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?
Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).
The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.
In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).
Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.
First off, the longest time to break something broken from the get-go award goes to CERT :)
But glad to see they fixed it, maybe it'll make CERT something more then amusing now. Eg: "You just got that fixed? I mean CERT will be releasing an advisory any day now!"
Second, for those who don't understand the role of exploits... I worked for a software house as a sysadmin/manager at one point. It took the IIS valnerability and the speed of a working exploit coming out on BUGTRAQ to prove to our head developer that he needed to check for buffer overflows in code, as he previously felt that creating an exploit would be impossibly hard.
Once again, thanks CERT!
----
Remove the rocks from my head to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
The government tried to stop encryption technology from getting out because they feared its use by black hats. DeCSS is an exploit, of course... seems like value judgements are being made about people, not principles.
1) CERT is way behind anybody else
They issued an advisory about wu-ftpd and rpc.statd in July or August when exploits, and proof of concepts, were on bugtraq in late May.
2) CERT has turned into a laughing stock.
The funniest thing I think I've seen in a long time is Jamie Rishaw's mock advisory about the Sony Aibo. This is just a slap in the face of CERT.
I'm not mocking the concept... an entity such as CERT serves a very big purpose. Being associated with the SEI one would think a much more active one. However since white hats are just as skilled as the black hats it doesn't take somebody at the SEI to write an exploit. By the time they do, somebody has already posted it to bugtraq or it's already out in the wild.
Just my $.02.
Of course, not telling exactly what the exploit is doesn't do a thing...all the script kiddies can easily go to one of the other sites mentioned and find out what the problem is and how to take advantage of it. Unless all of the websites decide to collectively not give out the exploits, it doesn't really do any good. HOpefully, the other sites will follow suit...preventing the faulty software from script kiddies.
The anti-salmon
I mean SecurityFocus/BugTraq has been doing full disclosure forever. Why didn't CERT start sooner? And if the k1dd13s want exploits they can get them from SecurityFocus or Packetstorm or something.
Sometimes you by Force overwhelmed are.
They've set up a 45-days after the fact disclosure policy, but they also put a bunch of loopholes in there allowing for later (or earlier) disclosure based on "negotiations" with the affected vendor and also the severity and sensitivity of the hole. So essentially what it says is "we'll disclose holes 45 days after they are reported, unless anyone gives a good reason why not, where "good reason" is solely up to our discretion." Not really very cut-and-dry, when you get down to it.
I don't see as the exploits are needed. Sure, they should release them to those responsible for fixing the software, but there's no need to release them to the general public (unless the general public is who is responsible for fixing the software, as in Linux).
Besides, it shouldn't take anyone more than a day or two to write an exploit, anyway.
45 days seems like a long, long time. In a single day, the average kiddie can go through a hell of a lot of computers. Do vendors really need that long to provide a fix, or are they just dragging their heels?
Haha, this can't be good for Mickeysoft!
Open software is no biggie it they did it 45 hours later! MS might not fix a bug after 45 weeks!
With 45 days of secrecy, that gives companies a month and a half to put out a patch. This is probably way too long. 15 days to put out a patch is a bit more reasonable.
Of course, if you consider it as 15 days to put out a patch and 30 days for people to get it installed, then it isn't too bad.
Personally, I think it should be a two-tiered policy. 15 days of secrecy once the software vendor has been notified. Then, if a patch has been released that fixes the problem, an announcement of "unspecified security problem" with a reference to the patch should be released, followed by an explanation 30 days after people have had a chance to install the patch. If no patch is released, then the full details are released at the end of the initial 15 days.
Oh well, 45 days is still better than never--much better.
Why do they insist on waiting for 45 days while other security organizations (bugtraq, packetstorm, securityfocus) release them immediately? Doesn't this just hurt people who rely only on CERT (like some people i know)?
Considering that the vendor companies have limited resources, it's the only way to make most of them take responsibility for their own product's quality. As a member of the InfoSec community, this warms my heart.
I think in general when bugs are first found, there should be a small window of time given to the developers to fix the bug. There is no need to publish a bug only to let every script kiddy out there crack your box. 45 days is pushing it way too far. Sure it's good that CERT is going to release more information, but I think that a more realistic set of time is three days. I think I read somewhere in which someone from OpenBSD stated that most security bugs can be fixed within an hour if the bug is known. Three days would be plenty of time. I know that some open-source zealots might think that all bugs should be reported immediately, but in truth this should only be the case when it is a true community project such as the linux kernel. Just because something is put under the GPL, does not mean that it doesn't have a main set of centralized developers.
There shouldn't be a blanket rule for security disclosure. If some thing is broken in Word fine post that up in 45 days if it not fixed by then the company might get a little bad press. But if there is something broken in a medical database (you notice that medical computers are always used to curry favor in these examples?) and they can't get it fixed in 45 days should the exploit be released anyway?
I say email the manufacturer, read what they have to say and if it seems like they are just sitting on their butts make the information public. But if doing so would endanger public safty maybe a different rule needs to be applied then "release after 45 days"
Time taken to disseminate an exploit world wide on IRC 2min.
Time taken to fix a security hole on an most BSD and Linux distros 10min-8hrs
Time taken to fix a security hole on a microsoft distro 1day - never
It's good that CERT are making strides in the right direction, as it will force tougher, faster action on the part of companies. Something that those companies have tried to avoid altogether through the new copyright acts, which made them exempt from haveing to make fixes.
The biggest question that remains, though -- is CERT, SecurityFocus, etc, legal, now? After all, publishing security alerts IS a form of review, unauthorised reviews are illegal, and I can hardly see names like Microsoft or Sun actively encouraging people to publish major security holes.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This makes you wonder how many undisclosed vunerabilities are floating around the programs you use every day. I mean, what's securitty if you don't know every single detail about the program you are using. Even with a copy of the source code in hand it's not like you have the time to read it, your never safe.
Oh well, time to go bury my computer in the backyard.....
If they were to release the server logs right after the event took place, and explained what happened, they would be asking for trouble, so it is more likely that they will take a few days to write up the report, during which time a fix could be created. This is an interesting move though, and i wonder if, in the event of a hacker seeing the report, and using it to hack a different companies site, if they would be liable for any damages..
The point is that with the practice of full disclosure, there's a real opportunity for upset customers and damage to reputation for the vendor who released buggy software..... I'd guess that software vendors would do even less testing and concentrate even less on security if they knew they were free from the risks associated with full disclosure.
If anything, what's needed is something that punishes software vendors for buggy code.
PJRC: Electronic Projects, 8051 Microcontroller Tools
I don't see why you say his manager sux. option 1: waste shitloads of money and blow an entire strategy which may make your company successful to fix a bug that may or may not effect you because you can't assess the situation properly or 2: ignore that "potential problem" and be cracked by some juvinile that will probably just install an eggdrop bot on your box but at worst could down your server for two days. Either way there is risk, you have to weigh the risks to make your decision.
How we know is more important than what we know.
Heh.. firewalls. Yer right. You know what "firewall" means to most companies? A wasted machine. "Can we use this box to run sendmail?" "Can we run apache on this machine?" "Why can't I ftp to the machine in the server room with all those EFTPOS terminals connected to it?" This is why companies started selling sealed boxes with "firewall" written on them, so people wouldn't think they were real machines. Unfortunately none of these companies can make a secure product (basing them on winnt doesn't help) and the tekniq for getting around firewalls is as long as your arm.
How we know is more important than what we know.
bah. Writing bug free software is expense, and customers don't care about security. There's a way out of this riddle, but it doesn't involve market forces.
How we know is more important than what we know.
I like the 45 day and then disclose idea because it's kind of like MAPS blackhole list. I'd like it even better if there weren't any 'negotiations' involved, but whatever. It's Carnegie Mellon, so it must be cool. =)
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
The Meaning of Life
great comedy company.
That's right folks. It should be illegal to post cracking tools and exploits. Why? Well because it's damaging to eCommerce because crackers will use it. Besides most of this stuff could be considered illegal because of reverse engineering which is indeed banned under the DMCA which, before you start bitching, is a morally just and much needed law to protect large corporations. So just shutup and eat at McDonald's and wear Nike shoes, and drink Coca-cola, and listen to Britney Spears, Nsync, or whatever other trendy music the RIAA wants you to listen to. Remeber, you don't have the right to choose what you do with your so called property or even your body so just live with it.
Knowing the detail of a vulnerability enables real risk assessment. How much of your systems are at risk? What's the value of what's at risk. It's impossible to figure this out without some notion of what the vulnerability is.
Security Admin: "We need to immediately upgrade all our servers to fix a serious security bug?"
Executive With Money: "What's our exposure if we don't?"
Security Admin: "I don't know. CERT just says to fix the bug."
Executive With Money: "And we are supposed to pull people off our Vitally Important Marketing Strategy Project to immediately fix a security problem, when we don't know what the problem is and what it costs us?"
If your children ever found out how lame you are, they'd murder you in your sleep
A lot of the "early" reports are motivated by the desire for credit for finding the bugs. It might seem petty and small minded, but so what? If that's your motivation for putting in useful work and publishing, who are we to criticize: go to it. If the companies/developers that have the security hole in their products enhance the glory for the discoverer, they might get more cooperation.
But early reports with exploits really light a fire under the fixers and create more awareness in the vicitms and potential victims, so in the long run it's a good thing, IMHO. But, MHO opinion doesn't matter: as I said, it's all about free speech.
This change is needed. There have been too many cases of vendors and users burying their heads in the sand about vulnerabilities. In practical terms, the threat usually exploits software bugs. not weaknesses of existing security mechanisms. The lack of vendor liability for errors and omissions in their software has meant that security-related bugs have been fixed only grudgingly. The UCITA has been a step backward; perhaps this will be a step forward.
This fairly dumb, but struck me as funny.
1) Unauthorised reviews are illegal.
2) In order to bring suit, MS writes a statement that SecurityFocus is publishing unwelcome bug reports, an illegal review of their product.
3) SecurityFocus never gave MS the right to issue a statement about the SecurityFocus product/service.
4) Therefore MS is breaking the law it's trying to prosecute on, just by bringing the suit.
Sorry. I'll be quiet now...
Drake42
The frustrating part is that the customer ultimately loses the most when an exploit is used against software they're running. In a way this is good - the more they suffer, the less tolerant they will be of insecure software - hopefully putting the vendor out of business or causing them to change their ways. Of course, in the meantime, they pay the price.
CERT is no longer the "Computer Emergency Response Team."
According to their FAQ:
CERT" does not stand for anything. Rather, it is a registered service mark of Carnegie Mellon University.
Its history, however, is that the present CERT® Coordination Center grew from a small computer emergency response team formed at the SEI by the Defense
Advanced Research Projects Agency (DARPA) in 1988. The small team grew quickly and expanded its activities. As our work evolved, so did our name.
When you refer to us in writing, it's OK to refer to us as the CERT® Coordination Center or the CERT/CC. Although you should not expand "CERT" into an acronym, it's appropriate to note in your text that we were originally the computer emergency response team.
Why the crazy sig? I'm a security engineer. Crabs are the favorite food of octopi, and if you put one into a tank with an octopus, it's soon dinner. The method the octopus uses to catch the crab is very much like how a hacker usually breaks into a system--he looks for design flaws and uses social engineering, avoiding the security mechanisms themselves. So I am in the business of ...
Who needs CERT then? Just tell company directly.
Get the credit yourself. =)
The sysadmins who need to be able to identify the security level of each components will be exposed to the 45-day black period. IMO, it is way too long. Sometimes, just knowing the nature of a security hole is enough to find an appropriate workaround and this doesnt have to wait 6 weeks.
I don't understand why they have chosen that 45 days magic number. It depends so much on the security hole.
I (with others) maintain an open-source software (delivered without any warranties). However, if I find out a security problem in our software, as a responsible maintainer, I would announce it immediately on the mailing list/web site and fix it as soon as I can. Unfortunately, you cannot expect this behaviour from major vendors or else, they wouldn't have put pressure on the CERT to remain protected for this period.
So my point is: "protect people, not vendors".
All humans are mortal. Socrates is a human. Socrates is dead.
"Dumb" users have an advantage of "Security by no access".
Basicly a server is granting limited access to the world. Even if that server runs only to deliver data to 3 people around the world it must grant enough access to everyone that it may verify the identity.
Any time you grant limited access there is a danger of a defect granting unlimited access.
"Dumb" users generally don't run server software and don't grant any access to start with.
They only run CLIENT software. Unless the client dose something amazingly stupid (like run programs as part of e-mail or wordprocessor files or use wordprocessor files as e-mail) the user is generally safe from harm.
(People or companys who ship client software that allows such things to happen shouldn't be trusted to write ANY software.)
If you run a server (like NcFTP) you really should know what your doing and read the BugTraps etc.
If your just a "Dumb" user then just use clients known to not do stupid things (like run scripts in e-mail, word processors or web browsers... or use word processors as net clients)
DeskTop Linux systems really should be devoid of server software as it's an unneeded security risk.
If you arn't an admin you shouldn't act as one...
If you are going to run server software you need to take full responsability for this...
There is no such thing as a "User friendly" server.
On this note... MacOs and Dos are the two most secure Internet operating systems.
This becouse they come shipped Internet UNready..
(Dos dosn't need Windows for Internet access.. just an Internet Network driver)
The only software running is the software being used.
Linux distros generally come with a bunch of servers installed by default and that is bad news for a workstation...
From my side...
This is the game of keepping crackers in the dark.
We tryed this in the 1970s... The result was techs who didn't know enough about security to protect themselfs against crackers.
This gave crackers the image of "All powerful hackers" in the 1970s.. but in the 1980s the reality came through as it was just a matter of not doing some really stupid things.
The techs didn't know thies were stupid things becouse they weren't talking to each other hoping to keep crackers in the dark. In the end only the techs were in the dark.
That is the problem here. In trying to keep the script kiddys in the dark you WILL keep they techs in the dark. That dosn't mean you'll keep the crackers in the dark.
If you publish NOTHING you expect the defect will be fixed before a cracker will discover it. The chances of this are increadably small.
If you publish the fact that the defect exists "I" can remove the offending software. The crackers can publish an exploite for script kiddys and a bugfix will take an unsuaully long time as most of the good guys don't have an exploit to work with.
Or you can publish an exploit...
"Dumb" users as a rule don't have anything to worry about.
They don't run the kind of software that makes cracking posable...
"Dumb" in quotes BTW becouse.. they aren't dumb just not techs. Thats gotta be reasonable.
I think however the casual user should know as much about computers as they do about cars.
Not enough to build one from ground up or how to fix an engen.. But enough to know to put gass in the tank and change the oil.
Yes the avrage user should know if a pacage he is using has a defect. But for now the News media dose that job pritty nicely... Malisa, and "ILoveU"...
They need not worry about defects in NcFTP.. as a rule the avrage user shouldn't be running NcFTP to start with... When they are.. thats the problem to fix...
I don't actually exist.
Why does the Slashdot community think this is obscurity? Just because someone doesnt disclose their security bugs doesnt mean jack. Everyone here can still look at the source. If you want to see security holes, go look at them for yourself.
These people are just trying to keep a secure system. You cannot do that very well by just telling all the script kiddies how to exploit your own product. ESPECIALLY when the other venders do not have a patch to fix the hole.
I personally commend them for waiting 45 days. There is no need for immediate anything. All this will do is add more script kiddies, more downtime, and LESS security. Youall seem to want the greatest security possible. Well I can tell you that if you leave yoru front door open, its not gonna do you jack shit.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
but you forgot the first amendment makes 'unauthorised' reviews legal.
In the sense that you can't go to jail for it, yes. In the sense that you can't be sued into poverty, NO. That's the problem with the civil courts today, any big company can pretty much wipe you out at will unless your case can capture enough public attention (a big gamble vs. just shutting up).
First, if there's a hole in a product that has been found, the company has been notified, and nothing has been done about it for 45 days, I'm sure someone has and is using an exploit by then.
Second, by publishing the details, and saying "hey, you knew about this for 45 days; don't you think your customers should know?", you're encouraging software companies to get their act together.
If left to themselves, no, they won't fix bugs out of the goodness of their hearts. The only people this sort of thing affects are the consumers; big businesses have firewalls and probably use better, more expensive products internally, wherever possible.
I think it's pretty sad that it has to be this way, but that's the way it is. Taking a laissez-faire attitude to big software companies doesn't seem to work, because there is too much potential for abuse.
I also don't like the whole "unauthorized negative reviews aren't allowed" business. Who cares about freedom of speech, eh? We can have unauthorized biographies of Bill Gates, and not unauthorized reviews of Front Page. Whatever you say, guys. For example, I did a lot of benchmarking between DOS and Linux's DOSEmu; my findings at the time were that DOSEmu was about 3% slower in raw CPU than actual native DOS (testing using the DOS 32-bit BYTEMarks), but that defragging a native DOS partition was *much* faster under DOSEmu, due to Linux's cache subsystem. Those are the facts; why should they be censored just because someone else isn't happy about it?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
pfft
45 days is a looong time.
Just think of all the things hax0rs can do to your server in 45 days.
At least if you knew about the exploit you could prepare yourself, even in a closed source environment where it takes a while to get a patch.