Apps

Consumers 0, Cybercriminals 1: The public disclosure debate


It's become great sport -- and often profitable -- to identify vulnerabilities in applications, operating systems, and LAN/WAN device controlling software. These activities are not in themselves a problem. It's the efforts of white hat hackers that help vendors tighten up product security and increase user awareness of high-risk environments or actions. But when greed or the need for 15 minutes of fame results in the untimely public disclosure of discovered weaknesses, some white hats start looking a little gray. 

I'm well aware of the arguments that claim vendors are slow to respond to reported vulnerabilities. Although progress has been made, companies such as Microsoft, Oracle, and other major suppliers must do better. Every effort must be made to shore up breaches in software security as soon as possible after identified. Excuses about modification cycle times must not get in the way of stepping up to deal responsibly with consumer risk. However, I don't believe this gives anyone the right to publicly disclose product vulnerabilities before they are properly dealt with.

Claims that public disclosure helps protect consumers carry little weight. Most consumers have no idea what to do with the information. They rely on vendor patches and product updates to maintain system assurance. The only winners, besides the person making the announcement, are the black hat hackers who haven't yet found the weakness themselves. I believe the most common reason some white hats make their discoveries public is recognition by their peers or by potential security company employers. 

The debate between these two factions about the appropriateness of public disclosure has only one winner -- cybercriminals. Black hats who don't have to work as hard to discover vulnerabilities on their own. The clear losers are the rest of us who use products for which assurance is degraded as additional attack vectors are made public.

The answer, as in most debates like this one, is cooperation by both sides. White hats must work closely with vendors to share information about the flaws they find. On the other hand, vendors must significantly shorten the time between discovery and remediation. Consumers will win only when posturing on both sides ends and sincere effort at securing personal, business, and national infrastructure begins.

About

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

48 comments
jmgarvin
jmgarvin

While it was a very interesting article, it really makes me wonder how MS can be so quiet about patching and very underhanded with WHAT they are patching. Bah...it's a wonder anyone uses MS products anymore...

Shaun.G
Shaun.G

Unfortunately, I have little choice at this moment in time... or would try to switch to another system... example PC-BSD... just to try something different at first.

Neon Samurai
Neon Samurai

VMware should pay me for the amount of times I post there name. If looking at other OS is what you want to do though, it's really the best way to go right now. You can build a VM for each OS you want to play with. If you break it, you'r not touching your native OS install and you can easily blow away the VM and start over as many times as you like. I finally got eGroupware configed and working last night in a VM. Once I get it syncing calendars and tasks with Outlook on a second VM; I'll blow away the eGroupware machine, build it nice and clean then really start to use it for home.

Neon Samurai
Neon Samurai

My feeling is that researchers should first contact the software/hardware developer with discovered bugs. With that report, they should also include a deadline for public disclosure. At minimum, developers should be contacted at the time of public posting. There's no reason for a developer to find out about a bug report first by reading the public posting. That kind of disclosure only surves someone's ego in a "ah, gotcha with your pants down big brother" kind of way.

jmgarvin
jmgarvin

Tom, you are totally, 100%, wrong. Security through obscurity does not work. Your claim that only the black hats win is very short sighted. Let's take a small scenario of a bank. Let's assume a critical remote exploit is found in the OS they use. Now let's assume that this exploit cannot be blocked at the firewall (takes advantage of web services or some such idea). The bank is in the dark, but the black hat (who is researching with the same tools and just as quickly as the white hat) knows that he can exploit this. So, he does. The bank loses millions due to data theft and loss of reputation, the customers lose millions due to identity theft, and the software company gets off scott free because not a soul knows about the exploit.

SkatingZebra
SkatingZebra

Okay, look at the flip side. "Let's take a small scenario of a bank. Let's assume a critical remote exploit is found in the OS they use. Now let's assume that this exploit cannot be blocked at the firewall..." Now, based on your argument, the maker of the OS publishes the vulnerability and warns everyone immediately, even before there is a patch available. The bank can't stop using the OS without shutting down operations, so it just has to continue to hope that no one attacks them. Of course, since the vulnerability has been published, it's not just the black hats that have the information, it's the script kiddies, fledgeling hackers, and just the plain old curious that have the info. The bank gets hacked and loses millions due to data theft and loss of reputation, the customers lose millions due to identity theft, and *because* they were given notice of the vulnerability, some bottom-feeding lawyer files a class action lawsuit. The bank pays millions to the lawyers, the so-called clients of the class get next to nothing (maybe a free checking account), the bank raises its fees in order to make back the money it lost. What has been gained from the early warning? In some cases it is entirely possible that an early warning would help companies and individuals by letting them decide to stop using certain software. However, when it comes to certain types of software (especially OS), notifying everyone of the specific vulnerability without researching it first won't help at all, and may hurt.

jmgarvin
jmgarvin

If the bank knows, they can monitor for possible security breeches that the exploit may cause. They can possibly harden up their firewall and IDS/IPS...and they can even keep a close eye on the logs for the exploits finger print... So the bank CAN do something if they know about it.

apotheon
apotheon

The bank could even use [b]different software[/b] that doesn't have the same vulnerability to run that particular part of its business, if it really has to. At least, it could, if the bank's IT department was smart enough to avoid vendor lock-in.

Neon Samurai
Neon Samurai

If they know where the issue is, they can tune there IDS to watch it more closely and put more resources into vetting and validating any transactions that may occure from that known issue. Everyone say it together now: Obscurity provides no security. Obscurity provides no security. Obscurity provides no security. Obscurity provi...

Shaun.G
Shaun.G

I am often reminded of "where there is a will there is a way..." and if a person desires to gain entry to a property they will... If a person wants to gain entry to computer systems, they will... irrespective of the security... they do it because they can, and because they want to... True security lies in the elimination of wondering what is behind the security fence or door that they do not want me to see? This comes from childhood of wanting to see what is behind the closed door... Did anyone here never experience in childhood, the desire to know what was behind a closed door? Or in the cupboard you could not reach or that was locked? Its difficult to stem this type of curiosity...and leads to people commiting crimes... its not the cause and I am not saying it is... I am just saying it can be deemed as a motivational factor.

Neon Samurai
Neon Samurai

Sure, the old motivation was curiousity; get in, look around, get out without causing damages or taking trophies. Today the break and enter artists are not just looking around and leaving though. Today it's criminals with very real financial motivations for what they do.

Neon Samurai
Neon Samurai

I truly wish it was like days gone by when emailing an Admin from there own account to explain how you got in and how they can fix it didn't result in FBI/RCMP officers at your door. Ah, the larva days of high school when kids could do stupid things without today's hysteria and knee jerk "see we're doing something about it" responses. I can't argue that curiosity is not the best reason to learn any new topic of interest. For the script weenie it's still all about curiosity in the beginning but when one talks about crackers in general these days; its organized crime and financial motivations. A weenie may break into his friend?s computer or try and muck with the school's network but the other 99% of computer crime is being motivated by adult interests. Heck, even for the weenie's it's about how many machines you can enlist in a botnet to blow your friend off IRC or wherever keyboard cowboys impress each other these days.

Shaun.G
Shaun.G

You write "Today the break and enter artists are not just looking around and leaving though. Today it's criminals with very real financial motivations for what they do." This is true, and I do not deny it, and I agree, curiosity is not the same, however it is where it starts... and then the one who can see a financial gain from their curiosity become criminal.

nacht
nacht

Here's a scenario for you: An exploit is discovered in a vastly popular operating system that would enable the attacker to gain control over a user's computer by (insert whatever method here.) The person who discovers this exploit sends it to the company that makes the OS, and for argument's sake let's say that company actually responds in a timely manner and investigates the problem. Meanwhile, the public hasn't been told about this exploit, and... uh-oh... one of the Bad Guys discovers the vulnerability. Now he's spreading the word to all his friends, but the public still has no idea what's going on. While the OS-manufacturing company is working on a fix (at least, we hope they are), no one beside the person who discovered the vulnerability (and the Bad Guys) knows about it. Every day thousands of systems are being compromised, and the public has no idea they're vulnerable. You don't see a problem with this?

Neon Samurai
Neon Samurai

Ah, crashing Windows network stack. What fun that was back in the IRC days. How long did the Windows family remain vulnerable to that little gem before it was fixed? (We all did stupid things in high-school)

jmgarvin
jmgarvin

Who wants to try Port 139 on Vista and see what happens ;-)

frank.schafer
frank.schafer

If a white hat discovers a problem - I do not have any illusion - we can be (nearly) sure that a black hat did this too. The difference is: The white hat tells this the vendor, the users, sysadmins and further white and black hats (the public). The black hat spreads this information in the black hat community. If a white hat informs the public then a non-techie user which hasn't the possibility to fix this can at leasts stop to use the software until it is safe, sysadmins can involve workarounds or stop the usage, further white hats can work on a fix (open source only) and the vendor can do the same. If the white hat reports this only to the vendor all would be some kind of whorse. Nobody else than the vendor takes any action, it takes some time until a fix comes out and bad things are going on meanwhile - because the black hat(s) know.

apotheon
apotheon

Even better: If the vendor's the only person that knows, the vendor may actually sit on it specifically because it's not as big a PR fiasco if it doesn't. The argument that end-users can't do anything about vulnerabilities is ridiculous. Usually, there's some simple work-around that can be used, even if it consists of nothing more than ceasing to use whatever it is that's causing the vulnerability, at least until there's a patch. When the vulnerability is public, that patch is more likely to come quickly, so many people can actually survive just ceasing to use whatever application or service is at risk.

apotheon
apotheon

The business has to make a choice between reducing the loss to profitability by taking down critical functionality and potentially much worse loss to profitability by getting security compromised in some disastrous manner. That's all assuming there isn't some work-around available that doesn't involve shutting down the service in question -- which is at least as likely as shutting it down being the only work-around. There's also the option, if you actually know about the vulnerability, of hiring someone to develop an at least temporary fix. Last but not least (and perhaps most importantly), knowing about vulnerabilities [b]and how long it takes to fix them once they're discovered[/b] gives you the opportunity to consider migrating systems to different software when you decide that the risks involved in using software from an unresponsive vendor are too great. That's really the key here: the real reason Microsoft doesn't want us to know about vulnerabilities has [b]absolutely nothing to do with our security[/b]. It's all about the security of Microsoft's market share. If more people knew about how slowly Microsoft responds to vulnerabilities, Microsoft would be hurtin' for certain. Many people would be considering using software with vulnerability patch times in hours or days rather than MS software with vulnerability patch times in months or years. . . . and Microsoft simply can't have that.

jmgarvin
jmgarvin

You probably don't have to stop the service to mitigate the threat. The problem is that you need to KNOW there is a threat to mitigate it. Let's look at it this way, you go to the doctor for a check up and he doesn't tell you anything....you could be fine or you could have cancer, but you'll never know because he wants to make sure you are "secure."

nacht
nacht

At least if the company knows of the problem, they can investigate alternative solutions. Depending on the vulnerability, this could be as simple as installing a software firewall, or antivirus software, or increasing the traffic monitoring of their IDP system. Knowledge is power. Why wouldn't you want people to have the facts?

Shaun.G
Shaun.G

What if that service with the vulnerability is essential to the operation of the business, and thus ceasing to use it could cost the company loss of business?

apotheon
apotheon

Some people are so thoroughly wedded to the idea that secrecy somehow provides security that they absolutely will not listen to reason on the subject.

Shaun.G
Shaun.G

Its a case of "Dont confuse me with the facts, I have already made up my mind!" Yes, I agree... there are none so blind as those who will not see. Thus, there are none so deaf as those who will not listen, as they have made up their minds and do not want to hear the facts.

alaniane
alaniane

I agree. The only valid reasons for making the vulnerabilities public would be if consumers could correct the vulnerabilities themselves or if a product needed to be recalled. If a vulnerability is exposed before there is a patch for it, how can the consumer correct the problem. 1) Most users only know how to point-n-click. A simple command like 'dir' or 'ls' would be beyond them. It would be unreasonable to ask them to even think about attempting to correct a software vulnerability by themselves. 2) Even if they could program, they do not have access to the proprietary software. 3) How often do you hear about a software recall?

Neon Samurai
Neon Samurai

If a bug is being reported, there is already someone else willing and able to use that bug with poor intentions. Not telling the consumer only serves the vendor's gross profits and false presentation of quality (I'm looking at you and your commercials Apple). Most consumers are not going to grab there compiler and write there own software patch but if they can at least mitigate the risk and hopefully start to ask those awkward questions about lacking product quality.

Shaun.G
Shaun.G

I dont about others - but I dont think I have heard of software being recalled... just issuing service packs to fix it... This was the case in the company I worked for too.... and when I questioned them on it... they did not want to entertain the idea... Customer is King, I was told, and we were so busy running after them to put in ALL their demands, that they were forgetting to make sure that the products worked... and never gave sufficient training time to new employees (like me). Yes, customer is king, but the company should not be manipulated and controlled by them, and yes consumers have rights as I ahve previously mentioned, and if the company is to ensure the consumer is getting good software, then they need to do proper testing first, and set the customer (consumer) expectations that this is what will happen, and when the customer gets the software that works, then they will be happy... and thus king.

SkatingZebra
SkatingZebra

...happen all the time; they're called "Patches" or "Service Packs". :) Seriously, patches and SPs serve the same function for software that recalls serve for cars.

Komplex
Komplex

We have got to stop making excuses for Tech Companies pushing buggy and unsafe code onto a paying public. This isn't 1979 where the users have a clue of what they are doing. We're in the 21st century, hardware is a commodity and applications are consumer products. If any other product had the same problems with computers and software, we wouldn't let it in our homes, much less our businesses. If Microsoft, Oracle, et al, want to shut the white hats up, upper management should take a pay cut and hire a few more white hat hackers.

Neon Samurai
Neon Samurai

If one must use a hat colour, a "white hat" is a hacker. The degenerate subform of life that gleefully accept the "black hat" title are nothing more than script kiddies and Cracker scum. Cracker in both senses; the white trash of the computer community and shakespears "what cracker is this that danes. . ." Your bang on the money though; we need to stop coddling software and hardware makers, stop accepting low quality for high cost and stop making up excuses. We'd also then need to have a tech industry that competed on the basis of product quality and usable functions rather than wizbang marketing slogans.

SkatingZebra
SkatingZebra

Tom Olzak is right; demanding perfect software isn't a solution to the problem, nor is ignoring the issues with bugs and security vulnerabilities. The two sides need to get together. Komplex, I've often heard the argument you make above, i.e. that, "My car doesn't have these kinds of problems, my refrigerator doesn't have these kinds of problems, why does software have them?" Well, your refrigerator just keeps things cool. It doesn't spell check your mustard label, identify when you're out of chicken and order some more, throw the milk out when it has reached its expiration date, etc. As for cars, who hasn't had to go to a mechanic? How about the number of recalls that are put out per year? I'm currently driving the most reliable car I've ever owned, and I still have to have the oil changed, the tires rotated, and the engine tuned up. Please understand that I'm not saying that software companies should just ignore these issues, but the level of complexity of your average commercial software package almost guarantees that you're going to run into problems.

Shaun.G
Shaun.G

SkatingZebra, currently the technology is available (since at least 1998) for fridges to do some of what you are saying...

apotheon
apotheon

Note that Shaun G. said the technology exists to do "[b]some[/b] of what you are saying". Considering you were trying to come up with ideas of things refrigerators absolutely do [b]not[/b] do, I think 1.5 out of 3 ain't bad at all. The technology exists for refrigerators to detect when low on particular items and order them. The technology exists to at least detect when the milk has gone over, and let you know so you can throw it out, even if it doesn't throw it out itself (thus the .5). In any case, I use software that is capable of far more flexibility and far more complicated task completion than MS Windows on a regular basis, with a far lower rate of failure than MS Windows. Obviously, it's entirely possible for Microsoft to get its act together and provide something that doesn't crap out all the damned time.

SkatingZebra
SkatingZebra

I've never seen a refrigerator that will spell-check mustard labels. And if that technology is so readily available, why isn't it mainstream? Regardless, you're missing the point. Refrigerators are made to do one or two things as a stand-alone entity. The average software package usually has to interface properly with at least one or two other packages, and each individual piece of software is an order of magnitude more complicated than your average refrigerator. Although now that I think about it, I could have used the "throw out expired food" functionality during my college days...

Tom Olzak
Tom Olzak

Software isn't like other products. Many programs have millions of lines of code. It's next to impossible to eliminate all bugs in an application that size. The key is quick response to identified weaknesses. Again, the two sides in this debate need to meet in the middle and stop taking jabs at each other. The bickering and "one-upping" that pervade this issue are helping the people that really matter--business and private consumers.

Neon Samurai
Neon Samurai

Sure, software has thousands of lines of code and for a software bug in amongst all that code; fair enough, find it, fix it and have a slightly better product. Poor architectural design is not acceptable though. Missing a bug is one thing but throwing together a kludge of code with product quality as a distant last consideration is no good. As a side note, another way that software isn't like other products; hardware and physical products cost a great deal to reproduce and deprives the first owner of that item when moved to another owner's possession. Software is easily duplicated depriving no owner when copied to a second owner?s possession. I?m not saying software should be at no cost but it sure could be priced more reasonably. That?s a whole other debate right there though.

Shaun.G
Shaun.G

1/. If a civil engineering company had one third of their constructions collapse... how long would they remain in civil engineering? 2/. If a surgeon or medical had one third of patients die, how long would they remain as a mediacl team? 3/. If a teacher has one third of the students fail, how long do they retain a teaching post? 4/. If a software company produces continuous buggy software how long do they remain a software company? It is very likely there will be some who disagree with this post, if not all, and especially with the figure of one third, and want to know where it is from... it originates from a known failure rate of certain schools in my area, where a third of the students fail... I just extrapolated across other fields to make a point... and yes the students have a duty to study, but the onus is on the teacher to cause the students to learn, and if they do not, the teacher fails in this... and I am not saying that this is true for every student that does not learn... All I did was take the third across a range of fields... its hypothetical, but gives a good standard of care and duty owed by those producing goods. If those good as NOT fit for purpose (for example - sample code having a particular feature, but its not in the final product, that product is not fit for purpose according to law). If therefore software i.e. Vista, is produced and constantly has problems, then it is not fit for purpose. This is where my 4 scenarios come in... 1/. Civil engineering company would be out of business 2/. Medical team would never operate in the medical field 3/. A teacher remains a teacher 4/. The software company gets richer (Microsoft) The consumers need to stand up and do something, and stop being dictated to by the likes of Microsoft! I know - I am guilty of not saying anything... but part of the problem, there is really no place to complain to, apart from the courts, which is an expensive task for the average consumer, to effect.

BALTHOR
BALTHOR

This search for vulnerabilities is making engineers and proprietors nervous."Everything that we make in our corporation is perfect".You're looking everywhere but at the heart of the problem.It's like a room full of auto mechanics and nobody sees the flat tire.

SkatingZebra
SkatingZebra

Balthor, I think you're missing a critical issue here. One of the major reasons that Microsoft has vulnerabilities to viruses, malware, spyware, etc., is the fact that they make such a huge volume of software. Not only that, but it all has to work together, AND all the pieces have to be able to be automated and used by programmers. For example, in one of my early projects I used Visual Basic to automate the creation of documents for mortgages. These documents were created via Microsoft Word, but all of the pieces were programmed in VB. When you have this kind of interoperability and code access, you're going to have vulnerability issues. Yes, I think that the big vendors need to be much more aware of security vulnerabilities and do everything possible to secure them as quickly as they can. But asking for "perfect" employees to make "perfect" software is sort of like asking Congress to fix every problem in the United States. It's too big and too complicated a job, especially when you have a hacker "team" of millions poking at every possible entry point in your software.

Neon Samurai
Neon Samurai

It's not meant to start yet another one side vs the other side debate but you basically saying that Microsoft's products are swiss cheese because they all have to work together and allow inhouse developed code a high level of access between products. Yet, OS based on Unix architecture provide even more access by developer code to a much larger selection of software products and somehow this security issue, isn't an issue. I'm still back to beliving it's piss poor product quality. "we can't get it all to work together *and* be remotely secure" just doesn't cut it.

Shaun.G
Shaun.G

I think that the word PERFECT is used so often, and it is not fully understood. Perfect is used to mean totally without any problems, with faults etc... however, according Cassell's Dictionary, and the Online Dictionary, it does not necessarily mean that - it means working to completion, and nothing that is essential, is left out... See http://www.thefreedictionary.com/perfect

Hamish_NZ
Hamish_NZ

Heh, yep - asking programmers to make perfect code is like asking mechanics to make cars that never crash. The issues are the same: 1. The users of the car [program] have to use it in the proscribed and safe way. 2. The car might be perfect, but is the road [hardware, OS, network] perfect too? 3. The car might be perfectly safe and unbreakable, but I'm not going to buy it if it costs $5,000,000 to make it that way. Sure, we'd all like to own a Bugatti Veyron (hey, if that's not perfect, I don't know what is...)!

Neon Samurai
Neon Samurai

You can't blame a car maker for some idiot driver running square into a light pole on purpose but who is responsible when a brand new car off the lot swerves into oncoming traffic because of a loose steering column missed during the quality checks? car makers sure as heck can take the time to tighten the steering column bolts, include seatbelts, airbags and crumple zones and wrap it in a cabin cage that doesn't fold like a pop can. We'll still have to see how Vista's crumple zones take the impact. The previous product offerings are more like a carbon fiber body wrapped around a low density aluminum frame. When those suckers hit something, the body, frame and occupants all crush like a grape under a horse hoof.

Tom Olzak
Tom Olzak

I agree. The problem isn't that we're failing to produce perfect code. As a former programmer, I can attest to the fact that no matter how hard you try there will always be issues that pop up from time to time. So in addition to implementing processes that produce a high level of assurance, software vendors have to react quickly when a "miss" is identified.

Editor's Picks