| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20021205234140.12855.qmail@email.com>
From: sockz at email.com (sockz loves you)
Subject: Security Industry Under Scrutiny: Part 3
You say, 'Hail, Full-Disclosure.'
Full-Disclosure hits YOU for 492 points!
You cry.
First off I want to say that I'm extremely open to intelligent debate. The key
word in that statement being "intelligent". I am no longer paying attention to
personal attacks, or people who try to use buzz-words and trendy phrases as the
basis for their logic. YOU PEOPLE SUCK!
Secondly, THERE ARE MAIN POINTS AT THE END IF YOU DONT WANT TO READ THE ENTIRE
THING. If you hate reading, are short of time, or whatever, I'd still love for
you to read through the general jist of what I'm saying here.
That said, I'm writing today about the flow of information in the security
industry. Granted I haven't put much effort into this so far. I kinda started,
and then got side-tracked with legitimate work, then had some computer problems,
and have had to start again. But. I like what I have so far, so I'm putting it
up for comments and constructive criticism.
This wasn't where I started but I thought it was very interesting. I stumbled
across this while reading through Ranum's slides to his Blackhat 2000 speech.
He described the general process of the security industry as looking something
like this:
Flaw (not yet implemented)
|
V
Vulnerability
|
V
Exploit
|
V
Disclosed Vulnerability -> Detection/Assessment Logic
| |
V V
Toolz Patch
| |
V V
Script Kiddiez -------> Users install patch
(source: http://www.ranum.com/usenix/blackhat-2000-keynote.pdf)
I think this flow diagram kinda makes sense. The main issue for Ranum isn't the
flow of information though (at least not from what I could gather). I think his
real focus was on the role of script kiddies in the security industry -- their
relationship with whitehats and their purpose in promoting security. By looking
at his diagram we can see his proposed solution would be to remove the 'tools'
section from the process. For Ranum this ensures a smooth flow from flaw to
patch with minimal risk to security. It seems simple, sure. But I'm tempted to
think that maybe things are a bit more complex.
So I tried approaching the concept from a different angle, and narrowed in on
the whole "lets tell others about the bugs we've found!" scheme of things. I
think my diagrams ended up a bit similar to Ranum's but different in a lot of
ways.
________
| 1 |
____________ Advisory |????????| Advisory _________________
| Whitehat | --------->| |------------> | Software Vendor |
???????????? + Proof | Report | | ?????????????????
of Concept| Vuln | | _______________
| | | | | Mailing
| | -----> | | List In
| | ???????????????
| | Tool + _______________
| |------------> | | Whitehat's
| | Advisory | | Website
???????? ???????????????
_________
| 2 | Tool +
|?????????| Advisory ________________
_______________ | Process |------------> | Script Kiddies |
| | Whitehat's | Site | | ????????????????
| | Website ------>| Traffic | | ________________
??????????????? | | -----> | System Admins |
????????? ????????????????
What happens after the second stage is that the script kiddy attacks a system
and/or a system admin patches their system. As I continually state, a script
kiddy can attack many systems, while an admin can only fix one system.
I keep reitterating this because I think it's a very important point to make,
considering that script kiddies and admins find out about the bug at the same
time.
The way our current system works is that information is released to everybody at
the same time. This means that script kiddies find out about vulnerabilities at
the same time system admins do. Even if the vendor has been notified before the
bug was released to the public, this system relies heavily upon all admins
taking part, because if they don't a security risk is created.
In effect this system forces everyone to support it, and punishes those who
don't. But what is support? Support is usually charging clients for protection
from vulnerabilities that the security company makes known to everyone on a
regular basis. Support can also be a security company paying for whitehat's to
send in bug information. Support == Money.
But the fundamental problem with paying people for vulnerabilities is that you
create an economic dependency upon bad security. People start to rely upon
software flaws to provide money for car repayments or their mortgage. Why is
this bad? Because when people with adequate skill and knowledge look for money,
they are going to start to look for bugs in software. In this case, ISS pay for
virgin bugs that affect many systems (because this means a greater number of
their clients will need to be secured).
There's something very wrong with that picture.
As anyone who's read or listened to Ranum's work will realise, in making a
conscious effort to look for bugs we negate the argument that "hackers already
know these things exist". Maybe (though its a remote chance), one or two
hackers might have realised the same vuln. So what? If its anything like the
majority of posts to vuln-dev or bugtraq or even here on full-disclosure, its
not something that can be used as a weapon of mass destruction. That is, in the
hands of a few it poses little threat.
But as we know, low threat means low return on investment for security
companies. So by telling everyone about this bug, security companies know that
script kiddies will then be more likely to exploit the bug. Which justifies the
companies role in society as being able to fix security problems.
But I'm getting way off track here. So, going back to our first process...
________
| 1 |
____________ Advisory |????????| Advisory _________________
| Whitehat | --------->| |------------> | Software Vendor |
???????????? + Proof | Report | | ?????????????????
of Concept| Vuln | | _______________
| | | | | Mailing
| | -----> | | List In
| | ???????????????
| | Tool + _______________
| |------------> | | Whitehat's
| | Advisory | | Website
???????? ???????????????
In light of who will access this vuln information we can now pinpoint a few
areas in need of critcal improvement. First of all is the proof of concept code
being released into the wild via the whitehats website. Removing tools from the
net means that you remove the threat of socially inapt morons (who have really
good s34rch 3ng1n3 sk1llz ph33r) finding the information and using it to exploit
others. If you don't like this idea, or if you rely upon the internet to
transfer proof of concept code to someone who is legitmately seeking to improve
security then why not implement another measure, make this information harder to
get. You could try a 'members only' section, or ask people to email you with a
good reason why they should have a copy of the code. Of course these solutions
can be a bit dodgy... It would be great to hear some suggestions from the
community... (yes, this is a subtle hint).
The other main area of concern is the Mailing List In data store. This leads on
to process 3:
_________
| 3 |
|?????????| Acceptable ________________
_______________ | Process |------------> | | Mailing
| | Mailing | Mail | Advisory | | List Out
| | List In ------>| | ????????????????
??????????????? | |
| | Unacceptable ________________
| |------------> | | Trash??
| | Advisory | |
????????? ????????????????
_________
| 4 |
|?????????| Advisory ________________
_______________ | Send |------------> | Script Kiddies | (attack!)
| | Mailing | Mail | | ????????????????
| | List Out ------>| to List | | ________________
??????????????? | | |-----> | Software Vendor| (fix code)
| | | ????????????????
| | | ________________
| | |-----> | System Admins | (patch)
| | | ????????????????
| | | ________________
| | |-----> | Whitehats | (learn/copy)
| | | ????????????????
| | | ________________
| | -----> | Media/Society | (panic!)
| | | at Large |
????????? ????????????????
I have no problem with mass communication. I think its a great invention.
But when it comes to things like spam, where I start to get things that I don't
need, then I begin to see a problem.
In this case, we're saying that an advisory, which contain information on how to
compromise a system, is not the kind of information that should be available to
just *anyone*. I think there are two main problems with mailing lists:
a) Moderators should be doing more to ensure that the kinds of advisories that
make it to the list aren't the kind that can be used to compromise systems.
We need to be more careful about what we're telling society. Some secrets
are better kept from others because they are secrets that can _destroy_
others.
b) We need to find a way to remove the "script kiddies" and "media/society at
large" terminators from the process. Even if the advisory was written in
good faith that it will help security, it is being transferred to people in
society who are not bound by any professional ethic to improve security.
Unlike software vendors, whitehats, and system admins, these people can get
away with harbouring malicious intentions because they are not expected to
act any differently.
There are a lot of bad people out there. People who spoil the fun for everyone.
We need to design ways of transmitting information about security to people who
can _improve_ security and NOT destroy it. Otherwise the entire system fails.
To abrubtly CONCLUDE, I'd like to SUMMARISE with my MAIN POINTS:
1. I make cute ascii diagrams, doncha think?
2. We need to place better control measures in the following areas:
a) What moderators consider to be "acceptable" advisories
b) On whitehat websites that provide proof of concept code
c) Lists in general, because they are read by evil ppl and not just good
3. The security industry is getting a bad name for itself because of money-
grabbing "security consultants" and participants who leech information to be
used for malicious activities. We need to find a way to remove these kinds
of people from the system.
So what am I calling for here?
A new industry standard for operating business?
Yes.
Tighter cyber-laws for websites that seem to tell ppl "how to hack"?
Yes.
Computers and the internet were created to communicate and experiment. We have
turned them into vehicles for profit and malicious intent. As long as we are
supporting and communicating to those people who are destroying our society, we
are communicating our _consent_ for them to continue making things worse. You
say "information wants to be free", but whats the point in releasing something
into the wild if its going to be captured and trained to rape and pillage?
Let's start being more responsible with our work. Let's stop rewarding
malicious people with ready-to-go exploits. Let's stop educating our enemies.
<3 sockz
--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
One click access to the Top Search Engines
http://www.exactsearchbar.com/mailcom
Powered by blists - more mailing lists