An argument against OpenBSD, qmail, et al.

Much has been made about the security of various security minded, open source products like OpenBSD and qmail, but are these accolades warranted? The data seems to speak for itself:

“Only one remote hole in the default install, in more than 8 years!”
-http://www.openbsd.org

“My offer ($500) still stands. Nobody has found any security holes in qmail.”
-http://cr.yp.to/qmail/guarantee.html

These claims of nearly a decade of security do make a strong argument, the claims may have qualifications like how the insecurity must exist only in the current version or a minimal amount of functionality… however these don’t change the fact that the security record is excellent. Does a strong record mean they are secure?

You could argue that most systems have such appallingly bad audit trails, that perhaps they have been exploited by real attackers and just not by bugtraq junkies, but this would be just plain pessimistic and argumentative.

You could argue that OpenBSD is a downright rare operating system and even then mostly run by enthusiast and not high risk installations, consequently there has been minimal effort to break it. While this argument makes sense for OpenBSD it does not ring true for qmail, which is frequently listed as the third most popular SMTP server. Clearly it is more than just scarcity to account for a low rate of vulnerability.

The simple fact of the matter is that guys like Theo de Raadt and Dan Bernstein are vulnerability experts and very good programmers (or at least they know good code when they see it, I have no idea if either of them lift a finger or just “lead” like myself). They have done a remarkable job in removing more or less all code level errors that allow common exploits to occur.

If this is the case, why then do I feel that OpenBSD, qmail, et al are in fact poor examples of “secure products”? To understand that, we must first understand exactly what vulnerabilities are why they occur and more importantly, and why they are unavoidable at this time.

For the context of this document, it is important to understand both the classes of flaws that lead to vulnerabilities and their introduction within a product.

The seven classes (as defined by the Information Sciences Institute) are:

1. Incomplete Parameter Validation (Buffer Overflow)
2. Inconsistent Parameter Validation (Different routines w/ incongruent data formats)
3. Implicit Sharing of Privileged/Confidential Data (Covert channels)
4. Asynchronous Validation / Inadequate Serialization (Race Conditions)
5. Inadequate Identification / Authentication / Authorization (Trojans, Weak Passwords)
6. Violable Prohibition / Limit (Poor Bounds Handling)
7. Exploitable Logic Error (Poor Error Handling, Bad Resource Allocation)

These flaws may be introduced within the three primary elements of development (Requirements / Specification Design, Source Code, or Object Code), during maintenance, or even operation. 44% of these flaws occurring in the Requirements / Specification Design phase and 18% in the Operation phase compared to 30% in the source code itself according to Naval Research Laboratory studies.

Perhaps part of the reason such a large percentage of errors are introduced at the design level is because so few commercial products (an even fewer open source ones) even have a Formal Top-Level Specification (FTLS), much less a good one. This FTLS should state more or less exactly what conditions the product is to meet, and then in the case of a secure product the FTLS must be consistent its security policy. Much of the point of an FTLS is focused on validation, “Does this product do what we need it to?”

Products with an FTLS are then further verified with a formal (documented, precise, comprehensive) security policy, which has undergone formal (mathematical proofs, pre/post-conditions mapped) verification. Products lacking an FTLS may have either a formal security policy that has been formally verified or informal (un/incompletely documented, ambiguous) with no verification at this phase.

Where verification becomes more difficult is ensuring that implicit rules are not violated. Implicit policies differ from explicit rules in that they are not actually spelled out anywhere in the security policy. For example: “User data cannot exceed the allocated buffer” Is implicit while “Operators can delete logs older than seven days.” is explicit. While products with an FTLS can mathematically determine the implicit rules correctness, informal products merely address explicit rules (at best) implicit rules can only be verified with testing.

While testing is useful, (primarily for usability issues) it is not comprehensive enough to offer any real level of assurance as testing cannot prove the absence of vulnerabilities. Now review the flaw list above and think to yourself for a moment, “How many of these have you ever tested for?” Now keep in mind, I’ve only listed a few of the attacks under each classification and worse is that new ones arise all the time. How many of you knew what a Heap Overflow Attack was five years ago? Would you have though to test if such an attack could violate your security policy having never heard of such an attack? No amount of informal verification can overcome this lack of perfect knowledge and the potential infiniteness of the implicit rules.

Does secure software exist? Yes. Can secure software exist without formal validation and verification? No.

In time, as products harden, attackers will need to discover more varied attacks as the more trodden avenues become effectively shored up. New ways to exploit the flaws classes will be discovered and abused as there is currently no way to test such flaws, informally validated and verified systems will constantly find themselves in a race against attackers. A long history of success in this race is no guarantee of success in the future.

Cheers,

catch

Quote:

---

Originally posted here by catch
Much has been made about the security of various security minded, open source products like OpenBSD and qmail, but are these accolades warranted? The data seems to speak for itself:

“Only one remote hole in the default install, in more than 8 years!”
-http://www.openbsd.org

“My offer ($500) still stands. Nobody has found any security holes in qmail.”
-http://cr.yp.to/qmail/guarantee.html


You could argue that OpenBSD is a downright rare operating system and even then mostly run by enthusiast and not high risk installations, consequently there has been minimal effort to break it. While this argument makes sense for OpenBSD it does not ring true for qmail, which is frequently listed as the third most popular SMTP server. Clearly it is more than just scarcity to account for a low rate of vulnerability.

The simple fact of the matter is that guys like Theo de Raadt and Dan Bernstein


catch

---

Dan has more than Qpopper though, he has DNS stuff as well. His students were the ones that found those flaws in Linux. Now, ummm, Catch I do have to go with Qpopper being fairly secure here, if you offer cash and no one stands up and says "Look at me" that's at least got something going.

Open BSD on the other hand, well, SUSE does code audits, if they release the next SUSE after a very big code audit with all things turned off (Un-useable) they could say it was the most secure OS in the world too. SUSE was just given the OK for Govt use as it got EAL 4+.

I have to agree though that I've rarely ever seen someone actually using OBSD.

There has been a definite decline in the 'production' usage of OpenBSD. I think this is for two reasons. A) as you mentioned catch, the typical installation is on an enthusiasts machines; and many of those have abandoned it in favor of the more up to date and easier to use FreeBSD. B) Where OpenBSD used to be very popular in small ISP's and InfoAssurance/InfoSec applications, there are now dedicated, 'supported' commercial products on the market from folks like RSA, and EdgeBlue (BlueCoat) that have largely replaced them.

Also in my expreience anyway, IS budget managers seem to be very uncomfortable with products that don't come with a large degree of accountability on the part of the vendor. That's one reason why we continue to purchase licenses for TrustedSolaris. Besides being a great OS for our financial data/SAP, knowing that a Sun security engineer is only a phone call away gives folks a warm fuzzy.

Last, but most important these days for 'real' system managers working at companies in the U.S. is the dreaded and mandatory SOX Audit . If you haven't heard of this yet, and are an IS/IT manager or administrator, look out it can be painful. Systems like OpenBSD, and for that matter many Linux distro's don't have the necessary support to run products like Symantec's ESM; an absolute must if you need to provide 'proof' that several hundred UNIX servers have proper access controls, and that full system/group/user auditing is taking place on each one. Personally I love OpenBSD and am a big supporter, but realize that without some big comercial 'must-have' security product that runs on it, it's days are most certainly numbered in 'real' environments.

Great post.

-- spurious

Nice, enjoyable ( as usual ).

But ( nit-picking again ):

Quote:

---

Can secure software exist without formal validation and verification? No.

---

I disagree. That is like saying if a tree falls in the forest and no one hears it, it did not make a sound.

( Don’t mind me, I still think E=MC2 is incomplete )

Now if you said that the chances are extremely slim that secure software could be created without formal validation and verification, I would probably agree. But that does not mean it can’t. What you seem to be looking for here is what you termed real level of assurance .

Remember, software ( and hardware ) are made by humans. Humans are fallible. The system you describe merely creates checks and balances in an attempt to overcome these fallacies, but is not in-of-itself a guarantee. The motivation behind the creation of software varies, but the bottom line is usually money, fame, or a quick fix. These motivations propel innovation in the industry which is why we are at where we are today. Too much haste, too many people who don’t know and/or care about quality or pride in their work.

IMHO software flaws are discovered mostly by those motivated as described above. Flaws in “ secure software” are found and/or prevented by those described below.

What is needed are idealists, such as yourself. ( Just guessing here :) ) Those who believe the job is not finished until every avenue has been explored, examined, and accounted for ( oops, does spell checking count? ;) ) People who think not just in the here-and-now, but in the future, and how their actions and creations will be utilized and judged.

Well, while writing this, spurious_inode provided an example of the current state of affairs:

Quote:

---

... IS budget managers seem to be very uncomfortable with products that don't come with a large degree of accountability on the part of the vendor.

---

Accountability? That is just someone to point a finger at when what you did, did not work. But how much finger pointing can one do if one actually reads the warranties, disclaimers, liability limitations, etc. of the software they are relying on? Until the courts actually hold commercial software vendors responsible for what they peddle ( and the pendulum is beginning to swing ) there is only the illusion of accountability ( or, as they say, assurance ).

Just my thoughts.

Quote:

---

Originally posted here by spurious_inode
...<snip> IS budget managers seem to be very uncomfortable with products that don't come with a large degree of accountability on the part of the vendor. That's one reason why we continue to purchase licenses for TrustedSolaris. <snip>...

---

You've just summed up the pinnacle point in the argument against Open Source software in the business place that many of my 'long haired zealot' compatriots can't get through their thick pony-tailed heads.

I'm not against Open Source at all, but I can acknowledge why a lot of companies won't embrace it; your statement is the reason. If you're network security solution tanks and my company takes a major hit, if you can be found liable, I've just removed myself from the hotseat and put you on it...at least partially.

Ok, back on topic. ;)

Can secure software exist without formal validation and verification? No

well i disagree about this
and i think 100 % secure software exist... if it is a software that does not contain code... or does nothing :P and even donno if ppl will find something in it :P

Quote:

---

If this is the case, why then do I feel that OpenBSD, qmail, et al are in fact poor examples of “secure products”?

---

i wouldn't say poor...1 in 8 years
how would you describe other product...1 critical every 10 minutes
i would love to hear your description of some * products like windows, iexplorer... i think they will not be in your list of software

and about not lot of ppl using and testing qmail and freebsd and some open source... well i think that the guys who make the exploits in other products are the one protecting and running those ones cuz they use them, they live on them :P

I have personally never heard of any business software (including operating systems) being written using formal methods.

These might of course be true for ultra-critical applications (nuclear power stations, aircraft guidance systems etc), but I have never worked on any of those (thankfully).

I don't know how hard it would be to formally specify, even a very simple piece of business software. Probably impossible, due to the large number of informally-specified pieces of other software it would have to interoperate with.

You'd need a formal specification for any interface it used to interoperate with anything, including the OS. Business OSs don't have formal specifications (some very tiny subsystems of them might have very inaccurate ones).

Personally I don't believe that formal specification is useful in business software. In software to do mathematical proofs, maybe. In software to guide aircraft, possibly. In business software? No.

My rationale is:
- Formal methods experts are very few, and almost certainly very expensive
- Formal methods are obscenely difficult to do anything useful with
- Business software needs to be developed to a reasonable timescale and budget.

How many jobs do you see "Wanted - formal methods expert - must hold Compsci. PhD with specialisation in formal methods"??

Slarty

Quote:

---

disagree. That is like saying if a tree falls in the forest and no one hears it, it did not make a sound.

---

Without formal V&V a "secure" software product is little more than assumptions:

I assume this product the type of security I need.
I assume that the implicit rules have been sufficiently tested.
I assume that there exists no ways to take advantage of flaws that I don't know about.

As an example, your security policy states: "A cannot write to C. A can write to B. B can write to C." (this is really simplified of course) Can A write to C?

If you happened to develop a secure product without the use of formal V&V, how would you know?

Quote:

---

i think 100 % secure software exist

---

By the context it is clear what you mean. I agree, 100% secure software can exist, but such software cannot be developed informally. Otherwise you are left with a product that is "Tested Secure" (which can mean near anything) vs. "Proven Secure."

cheers,

catch

Quote:

---

'long haired zealot' compatriots can't get through their thick pony-tailed heads.

---

*COUGH*

You might want to view my profile before you start claiming that my "pony-tailed head" is "thick"..... The damned thing is _solid_...... and I'm not for open source in a business environment for many of the reasons already laid down here..... ;)

Slarty, there have been a number of COTS level formally developed products.

Quote:

---

I don't know how hard it would be to formally specify, even a very simple piece of business software. Probably impossible, due to the large number of informally-specified pieces of other software it would have to interoperate with.

---

A big component of formal structure and development is black box theory, it doesn't matter that you send to it or what it sends to, so long as the data falls within the range of some pre-approved format.

Quote:

---

You'd need a formal specification for any interface it used to interoperate with anything, including the OS. Business OSs don't have formal specifications (some very tiny subsystems of them might have very inaccurate ones).

---

Nah, read above about black boxing. Several buisness OSes have differeing degrees of formal design specifications (though few have comprehensive formal verification) and include AIX, HP-VV, NT, Pitbull, Solaris (trusted and un), IRIX, HYDRA, and SecureOS (the last two offer formal verification as well)

Quote:

---

Formal methods experts are very few, and almost certainly very expensive

---

Such experts are only needed by developers, not the end users and with the advent of automated boyer-moore theorem proves formal verification has gotten much simpler/cheaper.

Quote:

---

Formal methods are obscenely difficult to do anything useful with

---

Most new systems mimic the security architectures of previous systems, giving the developers at least a road map... and again these should be of little to concern for the end user.

Quote:

---

Business software needs to be developed to a reasonable timescale and budget.

---

Of course, the idea here wasn't so much "Is a tested secure product better than a proven secure product for installation X?" More to the point of what constitutes "secure" anyhow? The beautiful thing about formal models is that they can be reused and once you have one development is a much faster process with a better end product, however as a rule such products do tend to be slightly more expensive (though perhaps the size of their market is more accountable for this than) not prohibitively so, especially for financial or R&D systems.

cheers,

catch

As far as I'm aware, none of these systems have anything even remotely approaching formal methods used in any of their development; they're merely well-checked systems. Formal methods don't really work for real software, and that's pretty much the end of it.

If you see how much effort it takes to develop even the most trivial of functions by formal methods, you'd understand. As you're just an IT manager blinded by words, you won't.

Slarty

Quote:

---

As far as I'm aware, none of these systems have anything even remotely approaching formal methods used in any of their development; they're merely well-checked systems. Formal methods don't really work for real software, and that's pretty much the end of it.

---

As far as you are aware, you are just plain wrong. SecureOS Type Enforcement directly from Honeywell's TCSEC-A1 LOCK system. That is about as formal as you can get.
The security policies for the other systems are formally validated as well (even NT was designed specifically against the TCSEC-C2 criteria).

Quote:

---

If you see how much effort it takes to develop even the most trivial of functions by formal methods, you'd understand. As you're just an IT manager blinded by words, you won't.

---

I am not an IT manager and I am not sure where you pulled that from. I am an Information Security Director currently in charge of new product development for a multi-billion dollar defense firm's Trusted Systems & ICE (Info/Cyber/Electronic) Warfare department. (Though to be fair, I am searching for a new job.) So I might have a smidge of experience in this area, though I suppose if I were blinded by words, I wouldn't know it... but then again neither would you or anyone.

I am sorry that you feel the need to insult me to make a point, that is just sad.

catch

Quote:

---

Originally posted here by Tiger Shark
*COUGH*

You might want to view my profile before you start claiming that my "pony-tailed head" is "thick"..... The damned thing is _solid_...... and I'm not for open source in a business environment for many of the reasons already laid down here..... ;)

---

Uhhh, you're about as much of an Open Source guy as the coder of Windows. Besides, your pony tail is more like "I own a comic book store and think a hot date is a six pack and a good connection".

As for Open Source and liability.... Aren't those words just as offensive as "reward on results" is to a typical manager? SUSE and other companies do give you a bit more in this area then say Slackware, and they have idemnification in case hell freezes over and SCO wins.

And catch, I should point out than you're not a real Unix guy, is it possible that your opinion is swayed? And while on topic, you know of any GOOD docs on SecureOS and the others you've mentioned? I could google for them but I don't want crap, I want something you've looked over and said was good.

Another thing, for permissions which I'm sure have something to do with security ;) NT permissions as opposed to Unix ones, can you honestly set custom permissions on NT without Registry hacking? Or... Editing? Unix is quite easy for this without any re-learning.

I say relearning because in NT you set accounts and they set permissions, but Unix based stuff, chmod and chown... Ah I'm running around here.

Gore, I'm not a UNIX guy? UNIX is fine, nearly all secure operating systems run something functioning reasonably close to a Single UNIX Specification compliant environment on them. I do have a few qualms with a few elements of traditional UNIX security, but that is totally an aside. (Beside, you know I quite like AIX, and IRIX and various Linuxes/other Unices are very powerful systems, just not right for my needs.)

However, all of that has nothing to do with this thread. Here the point was to indicated that a strong "tested secure" history is little assurance of secure future. In fact in my original thread I indicated that the two example products have done an excellent job at delivering relevant security.

I'll PM you about the docs in a bit.

More or less all NT security functionality can be modified in the security/group policy editor and the given object's properties editor. The set permissions/priviliges for given accounts in NT are just templates that can easily be changed. In fact in the case of SYSTEM/Administrator vs. root I think you'd be hard pressed to find anyone who thinks changing root's permission/priviliges is the simpler task.

cheers,

catch

The enterprise security topics that I am pretty hot on right now are Role Based Access Control (RBAC), and true privilege separation. Unfortunately both of these things have the same problem; they are typically proprietary (e.g. Sun's RBAC) or they don't really 'work' like they should in multiple platforms (e.g. NIS+ netgroups).

Funny that these are classic enterprise problems. "How do I give the helpdesk the ability to restart only in.ftpd?", or "How do I limit remote login access to the financial servers to just these three machines?". There have been some pretty good attempts at these problems, i.e. sudo and netgroups, but none that I am aware of that provide a top-down level of administration.

I was asked by a SOX inspector what my procedure was for having Sun Field Service personnel rack and maintain my gold maint. hardware. It took me a while to understand what he was trying to get at, but it dawned on me that he was suggesting that because I don't stand there myself and watch it happen that our data could be 'compromised' by a rogue Sun guy. That my phone rings off the hook, my pager never stops buzzing on my belt, I have hundreds of emails to read, and dozens of machines to build before I go home doesn't seem to register with this guy. Point is that some security measures that may be 'secure practices' are too *****ing impractical to even consider. Same goes with software, if an extremely elite black-hat wants into your network the only thing you can do to stop them is pull the plug on your uplink. If a VP wants a sysadmin to do something questionable or unethical, and does it in a very threatening way, guess who will win that battle.

-- spurious

I fear my point here has been missed.

I did not say OpenBSD and qmail suck. (In fact I said they do what they do quite well.)
I did not make any mention of open source being bad with regards to corporate assurances.
I did not even suggest that more companies or products use formal V&V.

The idea here was to raise the point of, If a security hole is the system acting in a way other than it was intended... how do you know what was intended if their is no top level specification? The validation is then used to ensure that the product's security policy will actually meet those needs, and verification ensures that the security policy not only does the right thing, but performs correctly.

Verification is all about bugs and exploits:
httpd should not be able to be broken in a manner that propigates its privileges
users shall not be able to change the permissions on files they do not own

OpenBSD and qmail do this quite well. (not perfectly mind you, but very well and exceptionally considering their price)

Validation on the other hand is about design.
A user maliciously emails away a private document.

Did the user violate the security policy? Does the FTLS mention anything about what kind of data the product can export? If it doesn't, technically the system has operated in the manner it was designed to and this cannot be considered a hole.

Another example.
User A places a trojan horse in a shared directory that, when run by user B it copies all of B's private files to a directory accessible by user A.

Does this violate the security policy? No bugs we exploited, each user preformed an action perfectly legal as far as the security policy is concerned. User A created an executable and placed it in a directory they had write permissions on. User B executed a file they had execute permissions on. This process read files that it had read permissions on finally copied them to a directory it had write permissions on. Does the FTLS state that rights shall not be transitive? If not, technically this cannot be considered a hole.

Do statements about "No holes in X years!" still retain the same weight in the absence of an FTLS?

Without an FTLS and subsequently validation of the security policy... how do you know what the system will and will not protect? How do you know if it will meet your needs?

cheers,

catch

"If my net can't catch it, it ain't fish"

If I have a concept of security, and an OS meets that spec, then it is
secure (to me). If you have a (different) concept of security, and your chosen
OS meets your spec, then you will regard it as secure.

But what is the absolute, objective definition of security? Is it that the
software was designed to be secure, according to an approved set
of methods, assumptions and accountability policies? Or does an historical
record count for nothing?

All industry is based on feedback. You design a product to the best of your
ability, but not being God, you may make errors. Everyone has heard the
old jokes about english cars. One Jaguar mechanic finally put it into
perspective for me. "It's "engineered about 80-90%", he said, the rest is
up to the mechanic"

You could embark on the quest of engineering your product 100%, but would fail.
The last 10, and especially the last 5% of perfection tends to require more time than
the first 90 or 95%. The last infinitesimal bit will take an infinite amount
of time.

If you have very high security needs, you spend more time and effort
on design, because the costs of failure are high, but 100% is still an illusion
and a good track record is still the only yardstick recognizeable on this
planet.
:cool:

I'm not going to bother getting into the details of whether OpenBSD (who was receiving government funding until very recently, if memory serves) or QMail are verifiably secure because that depends largely on their use.

On the contrary, to say that they are bad examples of secure software because they haven't had what *you* consider proper Validation and Verification is rather amusing to me, especially given the evidence to the contrary. In a world of strictly theory I might agree with your idea Catch, however, we have a track record, we have evidence to indicate they are indeed secure software.

Now, considering the elements here:
- Perhaps not the best theoretical implementation
- A very good practical implementation
Is it a good idea to be discouraging programmers from considering similar design elements or programming techniques when writing their own applications or services? IMO No.

Quote:

---

On the contrary, to say that they are bad examples of secure software because they haven't had what *you* consider proper Validation and Verification is rather amusing to me, especially given the evidence to the contrary.

---

Again, I did not say they were bad examples of secure software. I merely presented the fact that although their track records are very strong, what does that mean? I have repeatedly said, they do what the do well and have a very successful history.

The idea here is to not look at security as how many holes something has... because really what does that even mean? Without knowing what kind of security the product is trying to present you cannot possibly declare the number of holes.

Is the example of email a private document out of the system good for security? Is it a hole?
Is the example of the trojan horse good for security? Is it a hole? This ambiguity taints the whole track record.

Clearly both of these examples are flaws in the system's security policy, but since they are absent from the system specification noone considers them to be holes. This can be failed validation, since whatever security policy it does have does not adequently address issues of disclosure. Or it can be failed verification since the system fails to address the implict rules of disclosure. Which is it?

Now clearly if these confidentiality issues are not part of your requirements, such a system would be fine. To not count them as holes is fine, but to consider such a system to be a very (many even say "the most") secure system?

All of that aside OpenBSD and qmail (among others) are very good practical implementations. I have no desire to discourage programmers from anything... what I would like to do is encourage programmers to learn more about formal development models, system requirements mapping and specification development. If those developers were not constantly reinventing the wheel, imagine what they'd have time to work on.

cheers,

catch

Quote:

---

Originally posted here by catch
Again, I did not say they were bad examples of secure software. I merely presented the fact that although their track records are very strong, what does that mean? I have repeatedly said, they do what the do well and have a very successful history.

---

Actually you are; you suggested that perhaps QMail and OpenBSD, while not being particularly vulnerable pieces of software, may be being used incorrectly (your confidential email example, as one example of what I'm talking about). For the following discussion let's be extremely clear about this:
- Secure shall refer to overall implementation and use, from a very high level.
- Vulnerable shall refer to the actual vulnerability state of a particular piece of software.

I think you are somewhat confusing the issue by discussing security from a 1000 ft perspective in the same paragraphs as security from a 10 ft perspective. A lot of people seem to have mistaken your statements as referring to vulnerable software, whereas I do understand you are talking about secure software.

Quote:

---

Clearly both of these examples are flaws in the system's security policy, but since they are absent from the system specification noone considers them to be holes. This can be failed validation, since whatever security policy it does have does not adequently address issues of disclosure. Or it can be failed verification since the system fails to address the implict rules of disclosure. Which is it?

---

The real issue you are trying to put forth here is not anything OpenBSD or QMail have dominion over, and lies wholly under the control of the administrator. If you are simply saying that vulnerability-free software isn't enough to ensure a secure system, well duh, I thought that was obvious.

Quote:

---

All of that aside OpenBSD and qmail (among others) are very good practical implementations. I have no desire to discourage programmers from anything... what I would like to do is encourage programmers to learn more about formal development models, system requirements mapping and specification development. If those developers were not constantly reinventing the wheel, imagine what they'd have time to work on.

---

Quite frequently in my experiences as a developer, I've encountered situations where formal development models fail rather easily. For instance, you get one piece of bad analysis, and an application is broken and probably stays that way until a redesign.

Most of the top ten lists that are kicking around are focused on the more tangible technical faults with software design for a reason - we (people) are the other element in all of these processes. The industry is at the point (IMO) where the realization has set in that people are more harmful to systems than vulnerable software, which is why best practices guides and sites dedicated to helping people get better.

Quote:

---

Actually you are; you suggested that perhaps QMail and OpenBSD, while not being particularly vulnerable pieces of software, may be being used incorrectly (your confidential email example, as one example of what I'm talking about).

---

How is this using it incorrectly? Should OpenBSD not be used in instances where users may have access to private information and have some ability to export this information? Should OpenBSD not be used in any situation where an internal user may be malicious or stupid? This really narrows down its use, wouldn't you say?

Quote:

---

I think you are somewhat confusing the issue by discussing security from a 1000 ft perspective in the same paragraphs as security from a 10 ft perspective. A lot of people seem to have mistaken your statements as referring to vulnerable software, whereas I do understand you are talking about secure software.

---

Since I am discussing both validation (security) and verification (vulnerabilities) both are relevant. Unfortunately the two may sometimes be interchangeable.

Consider the trojan example. If OpenBSD had a specification it would state something similar to: "Subjects shall not be granted specific access to a given object unless the permission explicitly (owner) or implicitly (group/world) allow it." In the trojan example, a user is able to access files they did not initially have access to, without the owner intentionally granting them. Is this a security issue? Should the specification have stated that copied and new objects cannot be granted permissions beyond their owner without a formal change management procedure? Or is this a vulnerability issue? The access control system was not robust enough to have prevented this attack?

You could argue the issue either way as either approach would have prevented the specific hole.

Quote:

---

The real issue you are trying to put forth here is not anything OpenBSD or QMail have dominion over, and lies wholly under the control of the administrator.

---

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

Quote:

---

If you are simply saying that vulnerability-free software isn't enough to ensure a secure system, well duh, I thought that was obvious.

---

You'd think this should be obvious... yet the vast, vast majority of security focus is on vulnerabilities. Particularly with the examples of qmail and OpenBSD, just because they have few vulnerabilities they are claimed to be secure.

Quote:

---

Quite frequently in my experiences as a developer, I've encountered situations where formal development models fail rather easily. For instance, you get one piece of bad analysis, and an application is broken and probably stays that way until a redesign.

---

I agree with you here, unfortunately the reasoning behind this is more about the way corporations work and less about how formal models work.
Typically the specification is thrown together by someone who used to be a developer and they were such a good developer that they moved up to the architect/designer level. Unfortunately most of the skills required to be a good developer are not so useful as an architect. I can't tell you how many times I've spoken to engineers from large corporations that have really bizarre specs.

Infact one that I saw recently, the client had a very bizarre spec on the hardware portion of a project. They wanted something like a 120' 3.72" coax cable of some type. (I have no idea how much you know about physics so I'll explain.) A very bad attempt at a poor man's phase matching. They figured if the length of the new cable was the same as the other (of a different type mind you that actually needed to be that long) that the phase would be the same. Unfortunately this isn't true (different dialectrics, etc) and it put the new cable (which only needed to be about 6' long) under the noise floor. On the surface it would seem to have made sense, but not to a person who actually knows how to design such things. Long story short... blame the Peter Principal for your flawed specifications as companies prefer to use their own engineers as architects since "they are already familiar with everything."

Beyond all of this, there are exists several tried, true, and proven security models out there... and if none suit your needs, it has been my experience that a project with a custom formal model laid out by professionals familiar with such things and can develop proof of their model will be a much better and frequently cheaper, product... not to mention having a more predictable development schedule.
A bad model can ruin a project and scar all involved, and that is just plain unfortunate... but when you consider that every model should be expressed as a verifiable equation, there really is no excuse for such mishaps.

cheers,

catch

i started reading your intro post, but then 1/4 way through i raelised you have no clue about OpenBSD - so I can't be arsed reading the rest.

in the environents that I have seen recently, there has been an increase in OpenBSD usage. this might be because of all the recent publiscity Theo got. the US gov. Him getting the Open Source accolade from Stallman himself. who knows.

what sets OpenBSD apart from the rest is the developers and their efforts into the code. it has nothing to do with them being ultra super amazing coders but probably more to do with the fact that they devote alot more time and effort into checking the code that goes into it. so you don't have the same issues crop up as in other coder shops where the coders are foced to work very fast, and as soon as the thing is kind-a done, out it goes and the next project starts work. if anything crops up that is not kosher - no problemo we will release a patch until the thing's life cycle dies.

bah!

got onto their usenet & channels are read some of the communication, you might get a better picture.

Quote:

---

I can't be arsed reading the rest.

---

Wow...

You know what? At least I am a troll with a ****ing clue. Goddamn... You're cranky AND ignorant.

Quote:

---

what sets OpenBSD apart from the rest is the developers and their efforts into the code

---

There are more things that set OpenBSD apart. Although, with how obviously 1337 you are, you probably know all of them. I mean... just read their usenet posts.

You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth".

Oh and "It's Free" yea, as long as you buy the CDs.... Or do the FTP install... No remote wholes in 7 years in the default install.. Does that REALLY say something about an OS that boots up without anything even open to begin with?

I haven't been robbed in over 7 years, maybe because I walk around with an SK-47 and no money.... Wow I'm secure!

Maybe I can be a walking turnip like Theo now and have morons kiss me...

Quote:

---

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

---

Man, that's not even a computer issue. I could memorize the doc, write it out longhand,
and put it in the post. There's no technological solution to something that is a moral problem.
:cool:

Quote:

---

There's no technological solution to something that is a moral problem.

---

Aren't essentially all security issues, moral issues? Does this mean we shouldn't bother?

The implicit attack of course is a trojan or otherwise rogue process that attempts to export confidential information.

cheers,

catch

Quote:

---

Originally posted here by gore
You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth.

---

So many people reckognize a problem, and go on a tirade about how "insufficient" it is. This guy took it on as a challenge.

This is something more people should do to approach a situation.


Don't bitch about it........FIX IT!


$0.02


P:

First, there is no such thing as 100% secure code, and there never will be, anyone who thinks otherwise has lost their ****ing mind and needs to get out of this business.

Quote:

---

How many of you knew what a Heap Overflow Attack was five years ago? Would you have though to test if such an attack could violate your security policy having never heard of such an attack? No amount of informal verification can overcome this lack of perfect knowledge and the potential infiniteness of the implicit rules.

---

Second, how dows FTLS help against this? If you dont know the flaw exists how are you supposed to insure its not there? The full extent of format string vulns werent truly realized until around 2000, and those flaws had existed for years.

Third, even with a FTLS, people are going to make mistakes. Period. Humans write and check the code, while automated tools can go a good way removing some of the common vulnerabilities listed, some of these flaws exploit weak validation in one function that is 11 logical blocks away from the vulnerable function. Finding these flaws takes careful scrutiny from some of the industries best minds who have years of experience. You think every code monkey in the industry has that level of skill, and has the ability to forsee and remove these flaws?

Fourth, in these days of proprietary code almost every large scale project has to rely on functions, libraries and other forms of shared code, to which you do not have access to the source code. Its that or reinvent the wheel a thousand times. It is immpossible to verify this code will behave the way you expect and that it meets your security standards or that you are not inadvertantly introducing a vulnerabilty into your code by including this code, and that includes the operating systems themselves.

I'm not saying stricter guidlines on security practices and formal verification procedures are bad, far from it, but there are no silver bullets, and formal specifications always look good on paper, but as your own examples show, good software can produced without them, and I assure you bad software can produced with them.


-Maestr0

OFF TOPIC

Quote:

---

Originally posted here by spurious_inode
[B]The enterprise security topics that I am pretty hot on right now are Role Based Access Control (RBAC), and true privilege separation. Unfortunately both of these things have the same problem; they are typically proprietary (e.g. Sun's RBAC) or they don't really 'work' like they should in multiple platforms (e.g. NIS+ netgroups).

---

Sun RBAC is really a crap. Try to read instead BMC Control-SA software. You will be really surprised how a RBAC can be powerfull. But this is subject for another topic.

Quote:

---

Originally posted here by catch
How is this using it incorrectly? Should OpenBSD not be used in instances where users may have access to private information and have some ability to export this information? Should OpenBSD not be used in any situation where an internal user may be malicious or stupid? This really narrows down its use, wouldn't you say?

---

Erm, I wasn't taking that standpoint catch, which should be rather obvious as below I went on to state such things are implementation specific.

Quote:

---

Since I am discussing both validation (security) and verification (vulnerabilities) both are relevant. Unfortunately the two may sometimes be interchangeable.

Consider the trojan example. If OpenBSD had a specification it would state something similar to: "Subjects shall not be granted specific access to a given object unless the permission explicitly (owner) or implicitly (group/world) allow it." In the trojan example, a user is able to access files they did not initially have access to, without the owner intentionally granting them. Is this a security issue? Should the specification have stated that copied and new objects cannot be granted permissions beyond their owner without a formal change management procedure? Or is this a vulnerability issue? The access control system was not robust enough to have prevented this attack?

---

I think this is rather obviously a security issue (not vulnerability) for two reasons:
1. It requires that some person or vulnerable piece of software running on the OS already had higher privileges to get the trojan access to the rights in question.
2 The operating system itself is still doing its job as intended.

Quote:

---

You could argue the issue either way as either approach would have prevented the specific hole.

---

No, I don't really see how you could. The Operating System is not there to catch network or system design flaws, or really, breaks in third party software. IMO you're looking at situations security wise as totally wrong. You appear to have this idea that security is a wall where certain software introduces holes. It's generally much safer IME to believe that security is a LACK of a wall, and you have to put it up with as few holes as possible. This applies even to existing systems.

Quote:

---

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

---

It's a design issue that has nothing to do with QMail. Your example is bad because it is really taking issue with the RFCs that dictate how E-Mail servers should operate. People have known for a long time there are problems with the system, just like with IPv4. None of these issues have anything to do with QMail. Perhaps a better example might be situations where you can make parts of QMail vulnerable (it's been done courtesy of QMail's awesomely moduled nature, btw). The thing is, at that point, it's no longer QMail that's introducing the vulnerability.

Quote:

---

You'd think this should be obvious... yet the vast, vast majority of security focus is on vulnerabilities. Particularly with the examples of qmail and OpenBSD, just because they have few vulnerabilities they are claimed to be secure.

---

If I were to expand on my wall building example above, as I see it, using something I can count on as secure to a degree (you can never do it fully) lets me the builder keep the wall in good shape. Keep in mind also that the focus on vulnerabilities is largely due to the fact that software isn't going to react badly when you announce that it is a holey piece of shite (*coughIIS5cough*).

Quote:

---

Originally posted here by catch
Without formal V&V a "secure" software product is little more than assumptions:

I assume this product the type of security I need.
I assume that the implicit rules have been sufficiently tested.
I assume that there exists no ways to take advantage of flaws that I don't know about.

---

Here is a not-quite recent article regarding one of the very products illustrated for this discussion, and an issue over a 'security vulnerability'. Take it as you will, but I think it defends the position catch has taken.

Link to full article.

Quote:

---

...<snipped and paraphrased, my apologies to Jason Miller>...
(Dan) Bernstein designed qmail with security in mind. If everyone who wrote software actually made security a design priority, we'd be in a lot less trouble with vulnerabilities than we are now. But it appears this is too much to ask, because there's so much software out there that doesn't seem to put much more than a casual afterthought into security.

Secondly, Bernstein strives to write bug-free code. Although this is an unachievable goal, it didn't stop Bernstein from trying. His code has now stood the test of time, and has done so with a very small security vulnerability footprint.

The combination of these two factors has made qmail a very successful application for secure environments.

Qmail isn't perfect

Georgi Guninski recently published a vulnerability in qmail (albeit not a practical one), which can be exploited on specific configurations of some 64-bit systems. That's right. Even qmail has bugs. This shouldn't be a surprise to anybody.

If you're familiar with qmail, you'll undoubtedly be aware of the qmail security guarantee, which offers a monetary reward to the first person to publish a "verifiable security hole in the latest version of qmail". Bernstein has publicly denied this reward to Guninski, with the statement that "Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." This basically means that Bernstein doesn't consider this to be a security vulnerability.

Despite the fact that the vulnerability may have only academic merit -- it doesn't seem very likely that this will be exploited in the wild -- it is still a security vulnerability. As far as I'm concerned, the offending code should be fixed. I don't care how circumstantial it is; not fixing the issue accomplishes nothing.

The fact that software developers feel the need to maintain some sort of "clean record" that might be more important than tidying up even potentially vulnerable code, is quite disturbing to me. If the information security industry is creating this kind of environment for developers, then we're doing something wrong.

A clean record counts for nothing
...<snipped>...

---

I felt it was important to point this out to you all. Dan does not feel inclined to acknowledge this as a threat. Jason (that author) clearly feels it is a valid vulnerability, regardless of likelihood of exploitation. At what point does a threat become an "official" vulnerability? And by whose voice/hand?

I don't have the answers, I'm just throwing this in to stir things up^U^U^U see what you all think. ;) I do think that Jason's message, in closing the article, was paramount, even though his position may be opposite of catch's. 'Practice' is more important than 'polish'.

I read about that vuln, but had a laugh when I read:

Quote:

---

Details:
note:
- you need more than 4GB memory per process for this.
- gdb line numbers may not match because of small changes in qmail src
- tested on athlon64 8400+ with linux

---

And then again, this vulnerability is mitigated by the fact that no, I doubt there is anyone out there dumb enough to give each process more than 32 bits of addressable memory. Hell, QMail can run corporate mail services for 1100 users without choking on around 250MB of RAM peak (#s from memory). I'm trying to imagine a system where a single mail server would ever need that much RAM.
By the time anyone comes close to being able to exploit this vulnerability, there will be new versions of the software because it will be commonplace to have 64 bit precision and addressability. But it is still a vulnerability.

Maybe if Hotmail, Yahoo, AIM mail, Gmail, and Hushmail all ran on the same box :)

This is a security discussion, as such. although this is a little off topic. I think still valid as a metaphor (perhaps).

In a shop I used to work in, the insurance company, that under wrote the loss from theft, insisted a five leaver moron (or is it mortice) lock was fitted to an external door. The lock was a tried and tested security mechanism. The door unfortunatly was patched and painted to all hell. This equalled a door you could open by leaning against. Even though the shop had spent, comparitivly speeking a lot of money on a secure lock.

Quote:

---

Originally posted here by gore
You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth".

Oh and "It's Free" yea, as long as you buy the CDs.... Or do the FTP install... No remote wholes in 7 years in the default install.. Does that REALLY say something about an OS that boots up without anything even open to begin with?

I haven't been robbed in over 7 years, maybe because I walk around with an SK-47 and no money.... Wow I'm secure!

Maybe I can be a walking turnip like Theo now and have morons kiss me...

---

First, let me thank you gore for telling us what you really think. :)

For me, this cuts to the chase on the whole question of 'secure' systems. Software and Computer Security are at odds with each other. It is the way it has always has been, and probably will remain for some time. I am an OpenBSD fan, but I also recognize that the meat of what you said is true.

If asked to build an FTP server, and put it in the DMZ for public, i.e. unrestricted use, I am going to grab some hardware and my Solaris 9 media and spend the next 5 hours installing the most minimal system I possibly can. Then further stripping it down to only the absolute essentials to allow Solaris to function properly, a secure and stable FTP server, remote logging over an SSH tunnel to a logging host. Depending on it's purpose, I may not even install the Tivoli client and do backups on this host; having all the truly important stuff somehwere safe of course for DR.

The point? In the UNIX world anyway, software = security liability. No matter how secure some experts say it is, or how much I spend on super-special-secure OS licenses and support, the more software I have installed the more avenues of attack I have left open. I don't have to spend every waking moment reading bugtrack to see if some useless piece of software is going to get me hacked; thus am free to get other work done too. That was the point behind the way OpenBSD comes by default.

bw, ... Actually, OpenBSD hard-cores will all tell you that inetd and common Unix services are all on by default, which is true.

Make sure your face is clean now, can't have no dirty dead...

Heh, so am I going to be here, in a BSD london dongeon? ;)

You know I say what I feel :)