Slashdot Mirror
Security-Meantime Between Rootshell?
darthtuttle asks: "Hardware has a concept of meantime between failure, so how about applying a similar concept for software. Here's how it works. Cracks can be described by the level of access gained, some examples are: remote root, remote user (root if run by user root), remote group, local root, local user, local group, and so forth. Applications or services have their own measurements and descriptions as well. Most all types of cracks can be listed in an order and a higher level crack is equal to each of the lesser level cracks. For example: a remote root is also a remote user and remote group crack. Now measure the mean time between incidences! Do people find ways to break in to your system every day? Every week? Every month? Every year?"
"Rating a complex system would mean combining the ratings in some meaningful way. for example if you are measuring a RedHat install you might need to consider the name server, sendmail, and all other services running on the system on top of the kernel. Given a method to do this you could rate an entire infrastructure. I'm sure the insurance companies would love this. It would give them a way to measure the chance of you spilling the beans on your customers data.
I'm curious, do you think this would be useful if it could be done reasonably? What kind of mean times do you'd think you'd see for the various products out there?"
You missed the most important variable: "what is the system used for?". Obviously, a Pentagon webserver receives more attacks than a non-networked desktop.
The current trend among the linux community is to consider break-ins as Windows users would consider being infected by a virus - something that happens and that you can't really happen. You won't get any break in if you just try to half-secure your system - that is, if you read security advisories regarding your distro, and if you apply the correct patches in a decent period of time. Administrating a system securely requires you less time than doing stupid computations about the average time between two break ins.
okay, lets say you're in a class of 30 people (say a uni lecture or suchlike) and each person is 30 years old. Thus:
:(
30 people x 30 years of life each == 900 man-years (literally, the number of 'men' multiplied by the average lifespan _so_far_, i'm just saying that they're all precisely 30 for simplicity. As long as the individual life-spans _add_up_ to 900 it's no big deal).
Now, 900 man years -- someone in that class should be dead soon...
Mean Time Between Important Slashdot Articles.
Currently, 3 years.
I agree with both sides of the *BSD argument. I use OpenBSD and Linux every day. I play with FreeBSD sometimes. I use Linux for my desktop (need SMP, multimedia, and VMware) and OpenBSD for my home firewall.
I love the nice tight feel of the BSD's. I like the FreeBSD install much better than the over complicated or install-to-much Linux installs.
Even though I really like the BSD's, Linux has got a lot of momentum behind it at this point. Some of the coolest (for me anyway) opensource projects are all too often Linux-only.
True, a default Linux install can be less secure than say an OpenBSD install. Part of the problem is in the install and default configurations in Linux. I fully believe Linux can be as secure as OpenBSD if set up correctly. And there's some really neat security projects going on (SElinux, LOMAC, etc) and will really tighten up security for Linux (and offer more options and control than OpenBSD can at this time).
Linux also seems to have more choices for encrypted filesystems. I like the lookback single file/device vs. the CFS encrypting each file that the BSD's use. ppdd was/is cool too, waiting for a version that works with a recent kernel because it's awesome to encrypt your root filesystem.
It would not be difficult to measure the period of cracks in default installations of $OS with no added software, exposed directly to the internet at a low-profile location. Such numbers would be useless. Almost nobody actually has true default installs of anything, and virtually every system has configuration changes, software added or removed, various local administration practices enforced, etc. It also tells yout nothing about the effect of firewalls and intrusion detection, or the impact of merely *being* a higher-profile target or a site which provides certain services to the world.
In short, there are conservatively a million different inputs to this function, among the least important of which is what the system looked like after the initial OS installation. Until such magical time as OS vendors find a way to make every possible user happy with the set of software and configurations installed out of the box, customizations will remain the rule, and at least in the Unix world, so many customizations are possible, exercising so much different code from so many different sources, that no reasonable analysis of this type is possible.
In short, neat idea, but not possible to implement in any meaningful way.
I know quite a lot of math, both number theory and complexity and computability theory, and I read Gödel, Escher, Bach when it came out. To me, this sounds like a fair summary of the problem with this approach. There's no need to be so rude when you're wrong.
With hardware, you can imagine a scenario where you ask it to do exactly the same thing a million times (say, eject a disk); it can do it right 999,999 times and fail on the millionth occasion. But because of the problem the original poster outlined, in order to measure the time between failures of software you have to assess the frequency of the events which tickle the bugs; in the case of the behaviour of script-kiddies, this means that what's supposed to be a very simple statistical measure of reliability incorporates a complex and controversial social model of the behaviour of an unpredictable group of people.
--
Xenu loves you!
The security world has a concept of 'security assurance' - this is the confidence that you can have that a given set of security features (e.g. granular privileges, ACLs, audit logging, label-based security, etc.) actually work. This is taken from the old Orange Book used to rate computer system security, which has its problems but remains a useful model.
p ?theisbn=0201192462&vm=
Bruce Schneier has been talking a lot about the need for monitoring and response to intrusions, based on the reasonable premise that you can't prevent 100% of all intrusions for all time (even OpenBSD has had remote root holes some years ago, and most holes are actually due to specific applications). If you accept this, it seems sensible to define goals for monitoring and response times.
Defining such assurance levels is not easy - on one project, I wrote requirements for security assurance that defined quantified goals for such things as 'minimum time to detect break-in' and 'minimum time to respond to and stop break-in'.
If you are interested in quantifying requirements for security (and other 'soft' requirements such as performance, availability, reliability, usability and flexibility), have a look at Tom Gilb's work - his site is at http://www.result-planning.com/ and most useful book isn at http://www1.fatbrain.com/asp/bookinfo/bookinfo.as
Speaking as a part-time sysadmin in a Solaris environment, I can only hope that referring to Solaris as one of "the most secure OSes" was a grotesque joke. I would not categorically say that it is worse than Linux or Windows, but it is definitely no better- new exploits for Solaris come out all the time- currently I know of one rootshell exploit which is just hanging over our heads because it's in a subsystem which can't be turned off, and which Sun has so far failed to patch. I can't speak to the other OSes you mention, but "how many expolits do you hear of for such-and-such" is totally irrelevant to the actual security of the system, and the fact that you include Solaris in the list makes me rather skeptical of the rest of it.
"Never let your sense of morals prevent you from doing what is right" -Salvor Hardin
I can make the example of the company where I work (no, I won't mention the name).
They buy mostly dual-proc machines since, given processor obsolescence, they will last longer: it's the same reason why I bought a dual-proc at my home, and after three years it's not yet ready to be dumped.
Back to the matter at hand. Those computers (most running NT) sit idle 95% of the time, because the limitations are not CPU power, but ADMINISTRATIVE (what belongs to whom), ADMINISTRATION-related, what kind of setup is needed, whether it's to be high-availability), assorted problems with the OS (load a host more than X and NT - or Win2k - will go BANG), and general reliability problems (if you listened to Microsoft's specification, you'd have one site hosted on each server, no more.
Still, the double CPU thing somewhat limits obsolescence, and so it persists.
A better metric might be the ratio of intrusions/attempts
For the rest of the text, one have to assume that intrusion attemts are common enough to measure. If there are less than one script kiddie attempt/month or something like that, chances are very small that someone would direct anything but a random attack at the site.
But, I would also suggest adding an Average Intrusion Age, i.e., the number of days/weeks/years the methods used for the intrusion attempts was known to the general public. In my opinion, that way a metric on how interesting a specific site is to hack can be obtained;
The theory is that only people that are interesting in hacking the specific site will bother using the newest methods. Script kiddies will be forced to use older methods, waiting for the availability of public tools, and should the hack attempt fail, they are likely to focus on other sites instead.
By combining that metric with the average time taken by you to patch a sequrity hole from the moment it the hole was known to the public, one would get an indication of the probability that an intrusion attempt will succeed.
That knowledge, toghether with the number of attempts/month can be an indicator of if the systems sequrity is good enough.
Second comment:
Hardware can be meaningfully rated with a MTBF value because the errors are random, physical (often mechanical) defects. It is a measure of how likely a given operation is to fail.
With software, usually the same operation always fails. Software errors are design errors, not random failure.
I would like to add some nuiances to your statement; Yes, hardware failures due to malfunctioning or breaking components are random - providing the design itself is flawless, but there may also exist design flaws.
The same does exist in software as well. Some failures are caused by design flaws, others are introduced due to human error (typos that makes it through the compiler etc). The latter are per definition random, and can happend anywhere in the code.
When a software fault occurs, it does the same error every time that piece of code is executed with the same data. But the same applies to a mechanical component as well; if it can break in one way, that's the way it breaks when it breaks.
However, mechanical objects can break in an unpredictable number of ways since mecahnical (and electrical items) are affected by a hughe number of unknown and apparently random outside parameters, but that is true for software as well: Software very seldom execute in the same way - due to circumstances not controlled by the actual application (such as other applications, actual sequence of user or I/O input, swapping, availability of resources, timing and interrupts etc).
Thus, the failure might appear to be random to an outside viewer in the exact same way mecanical failures can appear as random.
The average number of deaths per 1000 people per
year is 9.3 so the MTBF for humans is ~108
man years.
I know for a fact my Meantime between rootshell is "forever".. Nobody has ever hacked me...
I also know for a fact nobody has ever TRIED or even cares about trying. My computer could quite possably have more security holes than swiss chease.. I'm a non-target..
I try to secure my box becouse random script kiddys don't care if the victom is a major bank or some random users game box. They just want to prove they are cool by distroying something.
I also avoid script kiddies.
So what would it count for?
Nobody ever hacks my computer becouse they don't want to. But ultra secure computers get hit daily. The diffrence is the importence of the box not the quality of security.
I don't actually exist.
Dual or quad CPU systems tend not to be much good for web serving as this tends to bottleneck on the network card, we've recently abandoned E250s in favour or netra t1s, but there are still a few E450s serving very heavy CGI loads. I will admit that I hate to see our database servers too, I'm going to turn one into a minibar when we finaly get rid of the dam things.
.233% CPU load
.00531% CPU load
One of ten Netra t1s...
Apache Server Status for (restricted)
Server Version: Apache/1.3.12 (Unix) mod_perl/1.24
Current Time: Monday, 21-May-2001 11:35:36 BST
Restart Time: Saturday, 19-May-2001 19:14:10 BST
Parent Server Generation: 0
Server uptime: 1 day 16 hours 21 minutes 26 seconds
Total accesses: 1650360 - Total Traffic: 3.8 GB
CPU Usage: u250.07 s78.74 cu7.47 cs2.02 -
11.4 requests/sec - 27.1 kB/second - 2444 B/request
25 requests currently being processed, 7 idle servers
One of two E450s....
Apache Server Status for (restricted)
Server Version: Apache/1.3.6 (Unix)
Current Time: Monday, 21-May-2001 11:43:40 BST
Restart Time: Monday, 21-May-2001 00:00:00 BST
Parent Server Generation: 234
Server uptime: 11 hours 43 minutes 40 seconds
Total accesses: 62688 - Total Traffic: 396.9 MB
CPU Usage: u1 s1.11 cu.09 cs.04 -
1.48 requests/sec - 9.6 kB/second - 6.5 kB/request
12 requests currently being processed, 6 idle servers
That is why for web work I use zope. I can assign acl on a per function basic in my python code. It would slow it down if I did it on everything however if judiciously used you can make solutions near impossible to crack.
I would love to have zope type acl capabilities in linux and am happy that a group is working on it to replace this user/group/world thing.
Check out the kind of security problems zope has had. Almost every one is actually an admin error that got "fixed" so others could not make that mistake. Ie making things essentially suid root. I think if linux had full ACLs with very find grain control and large list sizes the security problems in linux would drop like a rock.
Computer modeling for biotech drug manufacturing is HARD!
- Dell is now shipping a WireX product.
- Counterpane has licensed Immunix security technology for their internal use.
- We have two papers that will appear this summer at USENIX Security describing "FormatGuard" and "RaceGuard".
That's a matter of perspectiveCrispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase
- At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
- Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
- At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.
Crispin----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase
Just a friendly word or two, then: beware of complacency.
.|` Clouds cross the black moonlight,
I've been on a site where I specced out the firewall rules with the native sysadmin; between us, none of *our* boxes ever got cracked in the last 18 months. However, that didn't stop some schmuck sticking a RH6.x box with rpc.statd on a public IP# - give it a week, *boom*.
3hrs' turnaround including a forensics copy, custom build of RH and restoring data, I was quite proud of me. And it's never been cracked again, either. And then I finally found a writeup of a similar incident, and read `check for kernel modules', took another look at the forensics copy, and felt very small...
Maybe another statistic to add to `expected time to (between) cracks' would be `expected turnaround time' as well - part of your security strategy has to be having a spare box to replace anything with.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
Well, I for one use OpenBSD for all daily needs at work and that's what really counts. It doesn't matter moneywise if I use all the Linux ISO-image distros at home for free vs. that my company buys every single OpenBSD release for money and I put it on n+1 servers running everything from firewalls to DNS to desktop systems.
I still use a home rolled Linux system for home use because of the much larger number of multimedia applications and support for SB Live! and SMP in Linux which OpenBSD lack currently.
Other than that I have no reasons what so ever to run Linux on production systems at work whereas I can't think of putting any Linux system on the line to become cracked next to no time once exposed to the Internet.
++ Ray
"Put simply, oBSD is the single most secure OS in existance, and fBSD the highest performing."
I agree that OpenBSD is probably the most secure OS out of the box, maybe even the most secure OS period. But the idea that FreeBSD is the highest performing OS is just plain silly. Pick any commercial enterprise level Unix variant at random and it will outperform any open source OS including FreeBSD. When FreeBSD can scale efficiently to 64+ processors like Solaris and AIX then maybe it will be in the same ballpark as these operating systems. Until then its small potatoes.
Of course you could have been trying to say that that it was the highest performing *BSD variant, in which case I'd say you were right.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
if you havent seen the average large companies systems then you might be in for a surprise. check out http://www.rackspace.com/complex/complex_configura tions.php under the advanced configuration -- that type is routinely used for low end company websites with some database backends.
r ver_sun.php
For webservers check out : http://www.rackspace.com/dedicated/recommended/se
under the enterprise section. this is the average sort of website i deal with routinely. note that rackspace tends to skimp on redundancy...usually you see more redundant servers on most large company websites.
*sigh* i agree about the root exploits part but youre simply trolling for the BSDs which is silly IMHO.
any normal (read not yours) company will have at least dual or quad CPU hardware running in a cluster for their webservers..in most cases this may be outsourced or hosted at exodus or other NOCs. OpenBSD can support only 1 CPU at this time so that blows it out the water. FreeBSD is in a niche (not may admins can use it -- companies hire from the mass market so the skillset is definitely limiting fbsds existance) and doesnt scale properly as far as CPUs go (yes i know about the fbsd 5 improvements -- it aint here yet and still has the giant kernel lock).
Linux is gaining more and more since the availability of admins is there and its easy to set up (even if crackability exists) and is familiar enough with apache. it also scales well now with the 2.4 kernel and supports a lot of rackmount hardware at datacenters.
Solaris is usually what you find with netscape iplanet or apache at most companies..it scales well but costs an arm and a leg.
NT/IIS is another alternative for those cheapo firms who cant afford to hire admins to run UNIX.
--
The setup of the machine (as in the combination of software) is effectively irrelevant. Reported exploits most commonly happen in individual pieces of software. It _is_ possible to rate software based on the frequency of exploits reported in one piece of software. Even the most complex exploits hit enumerable combinations of software, not thousands of variations[1].
Widespread exploits depend on out-of-the-box insecurity.Similarly, security ratings of locks depend on their out-of-the-box characteristics, not when you've 'customized' them with a hacksaw.
However, the uncertainty of security ratings is almost certainly dependant on the install base of the software. So that, eg the certainty (not the value) of the security level of Windows variants is much higher than anyone else, while that of eg MVS should be fairly low as there are far fewer folk with access to mainframes.
-Baz
[1] This situation is different where there is a widely deployed insecure protocol, such that almost every implementation can be compromised by exploiting the same flaw in the protocol. However even this boils down for the most part to knowing the OS patch level.
Would you work for a company that boasts about its 'mean time to bankruptcy', or hire someone
who's improving their 'mean time between felonious drunken assaults'?
Hardware failure is inevitable and (generally) unpredictable. Gross statistical measures are one of the few meaningful ways to plan and budget for failures. Security is not the same way -- breaches can be avoided through vigilance and good management. Talking about 'mean time to exploit' is a cop-out -- it's surrendering responsibility to the whim of fate.
cheers,
mike
I think the concept is neat, but I don't think it involves a complex calculus to ascertain a system's security rating. You don't need to add, multiply, or average the package ratings on a machine....
Just read off the lowest one. The security on a machine is only as good as the least secure package.
Of course, you run into the problem of who will be the authority issuing these ratings. No software developer would be honest or forthright about their number (or the measurements would be entirely uncomparable), so a trusted external body would be responsible for the ratings... and they'd be liable for all manner of litigation from trademark infringement to libel to spoiling a market for a product by telling the truth about it.
So I predict it'll never happen. It's hard enough to get vague information about security breaches. Nobody'd dare quantify the risks.
I don't need large brains to have a good time.
I guess I am just lucky, but I have never had any of my systems compromised. I take care of about 200 systems and have never had any problems. I know of people who do experience this type of thing, but I find if you even pay a little bit of attention to security, you generally won't have any problems.
Russian Russian Russian RussianDollSig DollSig DollSig DollSig
First, as the poster above said, that is a hardware error, and exactly the kind of thing that affects MTBF numbers for various hardware devices.
:)
Second, cosmic rays do not actually cause memory errors. What can cause errors are alpha particles, usually given off by decay of trace radioactive elements in the ceramic casing of ICs. This is a problem for any IC, and they have to be designed to withstand it. I don't know if that is actually a significant source of errors in modern memory or not, though.
Of course, the #1 cause of memory errors is defective memory, but that is another issue entirely
Hardware can be meaningfully rated with a MTBF value because the errors are random, physical (often mechanical) defects. It is a measure of how likely a given operation is to fail.
With software, usually the same operation always fails. Software errors are design errors, not random failure.
While measuring the frequency of breakins is perhaps a useful metric, it shouldn't be confused with something like a MTBF for hardware. Also, the frequency of breakins due to script kiddies that scan and more-or-less target systems at random and just want a shell, or to deface your webpage, versus a deliberate and directed attack against you to steal/corrupt data are completely unrelated. The latter may have access to more sophisticated tools, better knowledge of your network and software, etc. Trying to apply numbers gained from random attacks to indicated your defendability against directed attacks is severely misguided.
Also, attempting an MTBF rating doesn't take into account visibility. If I drop most incoming connections through my cable modem and run a port scan detector, most people scanning my whole ISP will not even notice I am there. This doesn't work for a public website that many people know exists, even if it does drop their traffic to port 31337. Hardware MTBF is usually given in "operating hours" or some other well specified metric. I don't see how to do that for software. A better metric might be the ratio of intrusions/attempts, but since I would wager the majority if intrusion attempts, and even many successful ones are never discovered, that isn't a really good metric, either.
Why gives a damn about root compromises? Surely no applications on your sytem ever run as root? Since when does my FTP server need to be able to create files in /dev?
:) ] is trying to fix this, and is already being used in production systems. Butuntil its in the kernel nothing is being written for it and there's still vast quantities of broken applications.
No wait, I forgot - most Unixes (apart from TrustedBSD, Solaris, Trix, etc) are still using a completely non secure non granular permission system - ie, in terms of security, a broken one.
Ever service a machine provides should run under an account with the same name with permissions to do what the program does and no more.
Capabilities can provide some of this function, but they still can't fix some aspects of this fundamentally broken system. Ie, I have some word processor documents stored on a server. Some users need to read and write the files, another group needs to read the files, and all other users should have no access at all. There are ways around this, but its hacky and makes the system much harder to administer, compared to a four line ACL.
The Linux ACL and Extended attributes program [google
And while we're on the topic: please don't ever assume UID 0 belongs to an account called root (apps, not documentation). Drone about STO all you want, but obscurity as a layer on top of real security simply does slow crackers down. Haven't you ever used a honeypot?
Have you considered the fact that your box at work is behind a firewall?
That might explain the lack of scans against that particular box. (Your co-workers could always begin scanning your box, if it would make you feel better about all of those ports/services that you closed)
---
Interested in the Colorado Lottery?
Interested in the Colorado Lottery or Powerball games?
check out http://colotto.com
Are rated by number, that being the amount of time it takes to break it or cut through it.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
Your proposed standard levels of exploit are very unix centric. While such a set of "levels" might be appropriate (or even best) for comparing current unix-like operating systems, I think you'd want to try to make it more general. Things like: unauthorized permanent storaged read, unauthorized memory write, unauthorized code execution, unauthorized network write, etc.
If you applied such a system to our current linux, you might think it kind of silly since there would be a fair bit of redundancy (anyone who got root could do anything). However, I hope that in a couple years there will be several security systems that plug into linux that will make your current concept of root, user, and group privledges inadequate.
My linuxbox at work has been up for 3 weeks and not a single portscan, connect on telnet, rlogin or ssh.. My Linuxbox at home on cable.. 5-10 portscans per day, atleast 10 connections on telnet, ftp and other services per day. (none of them actually work of course, they're locked down) Its all about where the box is sometimes..
Humans have a mean time between failures of something like 900 years. That means for every 900/man years lived on Earth, someone dies (somebody correct me if I'm wrong on that number). Humans however have a Mean Time to Failure of about 72 years. That's the average time a human lives before failing.
Toddlers are the stormtroopers of the Lord of Entropy.
Like this: Gödel
We need a mean time between reboots. Just so people the linux vs windows camp can have something thats not subjective to say the next time a flame fires up.
Of course there is netcraft's ratings. but thats not really that acurate.
-Jon
this is my sig.
No one runs webserver's with MacOS, therefor no will will try to expliot them.
No-one except for the army that is.
-Jon
this is my sig.
Hmm, how do you do O-umlaut? (I know Goedel is acceptable in German, but won't be in a bookshop database)
----
I hereby inform you that I have NOT been required to provide any decryption keys.
Bruce's argument is that the possibility of an exploit puts all known security holes into the script kiddie category in this cryptogram newsletter
-- no sig
I'm curious, do you think this would be useful if it could be done reasonably? What kind of mean times do you'd think you'd see for the various products out there?"
no, because all you can do is measure the past of a piece of software and that doesn't tell about the current version or a modified version. the function for calculating the score for a piece of software would be unfair because it probably couldn't take into consider oldness and popularity of a piece of software and if it is open or closed.
it would be better to rate admins by their history.
It wouldn't make it as secure, because OpenBSD isn't only the kernel, it's the whole distribution. All of it is pretty closely screened for security holes, so it's naturally more secure than a Linux distro that just takes the most recent version of everything. It's also naturally not as up-to-date, which is one of the reason why it can't compete with Linux (or even the other BSDs) in a general comparison - it lacks too may features.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Vintage computer games and RPG books available. Email me if you're interested.
System security covers just that; systems. Not software. Do your users know what to do if somebody claiming to be 'Bob from IT' calls up asking for a password? Could a nice looking person in a suit, with a laptop, stroll into your office, sit at an unused cubicle, claiming to be a consultant, and plug into a live network drop? Do developers or other non-IT people have the ability to put up live systems, say, for development work, testing, or just because they happen to know where they can find a network drop with external access is? Do you have a disaster recovery plan? A hacker or an earthquake will destroy your data all the same. In a similar vein, what sort of locks are on your electrical closet? Can some idiot with a Linux boot floppy with a whack of filesystem drivers get to any machine with data on it? Go read up on the "Orange Book" computer security rating system. Honestly, software is the least of your worries.
Vintage computer games and RPG books available. Email me if you're interested.
Well, if you are right or wrong, the fact is that the 'trusted' features everyone is raving about are available for OpenBSD right now (even if not part of the main system) go read deadly.org to hear about the patches... Not to mention the 'TrustedBSD' project that aims to impliment ACLs on FreeBSD, which will no doubt spread to oBSD and NetBSD with security improvements in the oBSD code...
---=-=-=-=-=-=---
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
---=-=-=-=-=-=---
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Then isnt this a measure more of the sysadmin than of the software or infrastructure? Mean time between failing to fend off scriptkiddies.
.oO Kaa Oo.
Absolutely. But this isn't Security Through Obscurity.
The complaints about STO from the security community came from the days when fewer people understood security. Some people who thought they did (but didn't) reasoned that hiding information was the same as removing it.
This led to all sorts of strange things, including "proprietary" protocols and algorithms. Many of these secret encryption algorithms were easily broken because the algorithm was flawed. One of the first things you learn about crypto is that keeping an algorithm secret does not increase its strength. Similar things have happened to many proprietary protocols.
The concern about obscurity in any form has been that it's often used as a crutch, and that's led to a community backlash.
I would be inclined to agree with you. I can't talk for OpenBSD because I've not tried it, but I definitely appreciate the craftsmanship that seems to have gone into FreeBSD (a nice summary of which is presented here).
The rag-tag "throw a zillion monkeys at the problem" chaotic nature of the Linux evolution doesn't help for things like consistancy - something that I appreciate in FreeBSD. Then again, I'm a Win32 coder at heart... :op
..."How am I supposed to tell how long it will take to fix bugs we don't even know about yet?"
The problem is that you don't know the bug is there until it is exploited. So the question becomes: how do you estimate the number of bugs in a program? There are several rule-of-thumb based on statistics, but those aren't reliable enough to list as a spec.
The basic issue is that hardware manufacturers can test a statistical sample of their product and use those results to estimate MTBF for that product. With software, each program is unique, so it's difficult to say with any certainty that tests done on past software will extrapolate to new software, even if the statistical analysis is sound.
And when a program "breaks" (ie. a flaw is discovered), all copies of that software (or configuration) are affected. If a company buys 1000 copies of the same hardware, they can be confident that, on average, only a certain percentage of that HW will fail before the MTBF point.
With software, does it matter if the average time-to-exploit is high, if *your* current software package is hacked two weeks after installation? All one thousand software copies in the organization are now vulnerable; all have to be fixed/replaced. So that pretty MTTF spec isn't really very useful anymore.
thousand [K] [L]ines [O]f [C]ode
I wasn't downplaying the need for redundancy. Load balance a stack of single-CPU oBSD boxes and you're good to go. Notice that the (webserver) UltraSPARCs on the Rackspace page are all single-processor machines, too. And as far as a database, I wouldn't even consider using *BSD or Linux for a critical database. I'd go Solaris + VxFS or IRIX + XFS. (Perhaps Linux + XFS or Reiser after they've proven themselves).
The site www.army.mil is running WebSTAR/4.2 ID/70636 on MacOS.
The site 140.183.234.14 is running Phantom/2.2.1 on MacOS.
The site www.goarmy.com is running Netscape-Enterprise/4.0 on Solaris.
The site www.cia.gov is running Netscape-Enterprise/4.1 on Solaris.
any normal (read not yours) company will have at least dual or quad CPU hardware running in a cluster for their webservers
Jippity! If "any normal company" has clusters of dual and quad CPU machines to run their websites, I hate to see the hardware that runs their databases! And on the same token, I guess I haven't experienced these websites from "any normal company".
I agree that it's a bit of a shame that oBSD isn't an SMP monster, but that fact alone really isn't much of a problem these days, especially with 1.0+ GHz processors being the norm. Of the websites I help maintain, one handles an average of 1.2 million requests per day (average of about 14 requests per second, and about 8 GB/day). Granted over 95% of that is static content, but it's all hosted through a Pentium 233 running a heavily-patched version of Red Hat 5.2 and the load average rarely goes above 0.15. Another website handles the registration and accounts of a regional academic competition program and gets an average of 5 CGI hits per second. Using MySQL and Apache+ModPerl on a PII-266 atop Red Hat, the whole works chugs along fine with a load average around 0.10.
oBSD on just one modern CPU may have its limitations, but it could easily saturate a pair of 45mbit DS3/T3 links with dynamic (PHP/perl/etc) content without much cpu load at all.
Mitnick is/was nothing more than a social engineer sure he did some nice cracks but he was using the information that someone else found out about. He just decides to use this information.
of course "Social cracks" are the largest security risk but the orginal comment of "some exploits are so fucking complex it would take fucking Mitnick to do it" makes it seem like Mitnick was the best hacker that ever existed who is a false statement.
but measureing how likely a specific version of netscape will segfault at any given second might be usefull to those thinking of chancing an upgrade. Actually this is a silly idea. There is already a system in place in most companies that should suffice. It goes by many names but we call it the "Decent, Obtuse, Hellish!" System or DOH! for short.
I think you underestimate just how much I just dont care.
I always get confused with these arguments about which operating system is the most secure. Sure, out of the box most linux distro's are alot less secure than openbsd, if you spend the whole 10 minutes it takes to disable all the inetd servers except for the needed ones, disable telnetd, disable ftpd if it's not needed, check which binary's are running suid root, would this not make it as secure as say openbsd ? I rarely hear of any exploit code which attacks the linux kernel itself, therefore it's reasonable to assume the lack of security of a distribution is simply the way it was put together, not linux in general.
ASFRecorder doesn't actually decrypt the content. All it does is capture the packets sent by the server and reconstruct them into a file. If the stream is protected and encrypted with DRM, you can't play it without the license, even after using ASFRecorder. The thing is ... nobody uses the DRM protection options. That's why the author wrote the program, to send a wake-up call to content providers. Who slept right through it.
BSOD Properties and Other Customizations. This page has a little VB3 app to easily let you make the changes. Or, if you don't want to bother with that, it tells you what to add to SYSTEM.INI.
I made my BSOD red for a while too. But I found it induced too much anger in me, so I switched it back.
As far as hardware failure goes (MTBF, MCBF, et cetera), things like heat, dust, corrosion, and general wear-and-tear can be predicted accurately. However, when it comes to the mean time before crack, it's almost unpredictable. The utility for unlocking secured Microsoft WMA files was released the day after the format's launch. DeCSS took a while longer, but it was eventually done. ASFRecorder effectively circumvented Microsoft's intent to prevent users from storing copyrighted video content (I forget when the first version of ASFRecorder was released, but the final one is dated late June 2000). There are plenty of other examples out there, which show that the time it takes to crack something can vary dramatically. These examples prove that predicting the "mean time before crack" is like trying to predict the weather in New England down to the square mile: it's nearly impossible, you're almost always wrong, and it's not worth the effort.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
I'd imagine rating hardware would be easier, as the main failure points are physical components breaking due to heat, etc.. Software has a lot more variables, including the hardware it's run on, experience of the administration setting it up, and such...
www.Beyond7.com Insane modern art water sculpture.
They actually have people emplyed who specialise in CMM and a great deal of planning goes into it all. But then when it has a military application I guess you can never be too careful.
..Barny
None of which invalidates anything he's done. The risk of effective "social cracks" is probably the _largest_ security concern out there..
In that respect, then, your argument winds up supporting a "mean time between rootshell" calculation; for reasons discussed elsewhere, though, such an idea is pretty daft..
Secondly, I don't think there's any way of coming up with an objective standard, a base line by which such a meantime could be judged. No two servers are alike, and even within broadly comparable applications it's more complex than just measuring traffic to the server, average load, etc. Some servers are more visible, or more desirable (from a cracker's perspective) -- either from a kudos point of view, or in terms of the potential use that can be obtained from a cracked server. It's pretty meaningless to say "my server's been up for months without being cracked" if it's some no-name machine that nobody knows or cares about.
Security's also not just to do with the software -- the computing power of the machine also needs to be taken into account. You're not going to be able to crack a password list as quickly on a 486 as on the latest pentium machine, for example.
So: no, it can't be done, reasonably. And asking what kinds of mean times we'd expect to see is, frankly, trolling for a platform flamewar..
Art At Home
The reason why you can do this with a safe is because there are so many known quantities. You know what the safe is made of, and how it is built, and the properties of both, with no hidden surprises. The vulnerabilities of both stay constant over time as well; you don't ever hear about a previously undiscovered buffer overflow in carbon steel :) And finally, the methods of attacking safes and vaults do not change quite so quickly as hacking methods evolve, so you can know authoritatively what would be done by an attacker, and account for all of it.
For your security, this post has been encrypted with ROT-13, twice.
Software, of the other hand, is a digital entity, so its function doesn't change with time. If it was broken on the 10,000th time around, it was broken all along. Whether anyone noticed it was broken is completely another issue.
--- In the battle between the axis of evil and the one of stupidity, choosing intelligence is disloyal.
software does have a similar concept. i remember it from my software engineering course last fall. i belive it is "Mean Time to Failure" ;) go figure...
"Shut up brain or ill stab you with a Q-tip" Homer Simpson
Average time between failure is a mean value.
Time1+Time2+Time3/3 = mean Time
"Shut up brain or ill stab you with a Q-tip" Homer Simpson
Put simply, oBSD is the single most secure OS in existance
While a little fanatic, if you qualify it like "oBSD is the single most general purpose OS in existance" it rings closer to the truth. Of course, even the most secure OS in the world is worthless in the hands of an inept administrator.
She feels me I can taste her breath when she speaks.
In five years of running an ISP I never had any problems finding highly qualified FreeBSD admins. Linux is gaining more and more since the availability of admins is there
If that's your metric then perhaps Windows is the way to go. There's a ton of MCSEs out there!
Our company changed over to OpenBSD from Red Hat because we were fed up of all the root exploits, all the patches all the time, and the incoherent way in which linux as a whole tends to be organised - ie, linux is the kernel, not the OS. OpenBSD is the entire OS, and is much more sane, IMHO.
The problem with linux is the general chaos. Great for hackers, and definately much better for the desktop user, but oBSD and *BSD's generally are much better in production environments.
Put simply, oBSD is the single most secure OS in existance, and fBSD the highest performing. Take your pick, its no contest as far as BSD v linux is concerned for my company.
--Anticipation of a New Lover's Arrival, The
Sendmail 8.2.2: If I ran a mail server using only this program and no other ports open, I had a 100% secure system until some time in january '01. I'm not sure how long the software had been out, but let's say it was a year. So I run for a year, which gives me 1 year MTBF for the first instance. Then as the TSIG exploit came out, I would have been rooted. Now, does this mean I'd then have another year before i was rooted again? Of course not. If I didn't patch the system I would have been broken into the next day, the day after that, etc. up until the lion worm where i would have been broken into many times a day.
So is there any way to develop a meaningful statistic about all of that? I don't think so. Software is either broken or not, based on what exploits are available, and doesn't break on a regular basis letting a single script kiddie in once every 60,000 hours.
The difference is, of course, that hardware fails, statistically, in a more or less random fashion. Exploitable software fails once, and then near *constantly* from that one mistake.
During my first 5 minutes of looking at BlackICE output, I got hit from about 4 different directions as people scanned through the net...
Cryptogram March 2001 has an article about it, for example.
--
fifth sigma, inc.
How about Netware? I once helped someone set up a Netscape Enterprise web server running on Netware 5, which was a first for me.
I've searched the web for Netware exploits (out of curiosity only) and never found one for a current version.
--
Have crack, will moderate.
The occasional poster formerly known as jihad23
I like my women like my coffee... pale and bitter.
Let me clarify something here. I'm not looking for mean time between rootshells for a individual system, but for a type of system. For example, what's the mean time between exploits in BIND 8 in general, not your specific BIND 8 installation. The more general question really is, why don't we measure how often a product has flaws discovered. If I need to choose between RedHat and OpenBSD and security is my biggest concern I'm going to look at 4 years without a remote root exploit and chose OpenBSD, but what if I'm deciding against Solaris and HP-UX? What's the difference?
The reason I find this meaningful because it help measure work load. Am I going to take the machine down once a week to apply a patch, or once a year? The shorter the time between new exploits the more work I have to do to maintain it.
--
Darthtuttle
Thought Architect
Darthtuttle
Thought Architect
Yes I was incorrect it is KLOC... sleepy eyes =o)
The problems with metrics on software has always revolved around the abstract nature of software itself. Almost any sort of metric can be misrepresented one way or another.
Long ago, companies measured programmer productivity by using the KLOCKs, 1,000-line blocks of code. The more KLOCKs you could kick out in a given time period on a task, the greater the perception was that you were working harder. We all now know how easy it is to manipulate that perception. 500 lines to add two integers, sprinkling 1000's of lines of useless looping code documented to look like it's crucial to the system.
Proper measurement of failure is further compounded by the complex nature of most products written in OOP. Underlayered components, physical devices, and operating system issues could be mistaken as problems with the software application, when in fact the application itself requires no modification to fix the problem. Metrics also rely on fixed points of time as references which make matters worse as some problems are beyond the scope of the project (i.e. product works fine, but customer later upgrades video drivers that cause app to break).
Carnegie Mellon University has pioneered the software maturity analysis area with its Capability Maturity Model for software shops (think ISO9000). If I was a large customer (say Boeing), I would probably make my purchase decision more along the lines of the CMM rating of the software team that created the product rather than some silly arbitrary metric that most suits probably wouldn't comprehend anyway.