Slashdot Mirror
Domain: immunix.org
Stories and comments across the archive that link to immunix.org.
Comments · 160
-
Secure LinuxesAt the Linux Showcase in November I attended HP's presentation on Secure Linux and if you sweet talked the HP guys they would unlock the secret cabinet and give you a copy of Secure Linux. I also did a term paper on SE Linux last semester.
The two OSs are fairly similar in what they hope to accomplish -- isolate the risky software and users from the rest of the system so if something bad happens it doesn't take everything down. From the sound of the HP presentation, this is all HP Secure Linux does. You create compartments and then specify what the compartment can do. You can do the same thing with the NSA's SE Linux and much much more. I was really impressed with the flexibility offered by SE Linux. You can setup your system with about any security policy you like. The biggest problem is the great complexity. You need to do a good deal of research before even thinking about modifying the sample security rules that come with SE Linux. There are thousands of rules in the included security policy. This is where HP Secure Linux probably has an advantage--it's a bit simpler to user. Though I haven't had a chance to try it out yet.
You don't really need to pay $3000 for it either. The kernel patches are GPLed and part of the kernel security interface used by SE Linux also (NSA and HP have cooperated here). You are really paying for the tools, but those are just programs that make certain sys calls. It shouldn't be a problem to write your own open source versions. Though there might be a nice gui that would take more work to create.
If you are interested in secure linuxes also take a look at Immunix and EnGarde. Both also have kernel level security controls, but not to the level of NSA Linux. Immunix has a comparment system like HP Secure Linux called SubDomain. EnGarde uses the Linux Intrusion Detection Project.
A paper doing a detailed comparison of the four would be welcome!
-
Re:Interesting review, but...For a good book on security and programming, try "Building Secure Software" by John Viega and Gary McGraw. I am going to use this book as the course text in the next offering of my graduate security course.
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase -
Re:Solaris Sparc kernel-level stack protection.Yes, the article with the "canaries" is StackGuard.
And besides, you often don't need any shell code as such, there is enough cruft in different libraries that you can call to do your dirty work for you. See for example the last (windows) link of of sans buffer overrun page. Which is a good page to get you started on buffer overruns.
-
Re:Torches, anyone?Quite a pity that a freedom-loving person didn't think of this and patent it. Were I the patent owner on this patent, I would not market it as a product, and I would demand a truly exhorbinant licensing fee to use it, i.e. no one would be selling a DRM OS
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase -
My WishlistMy wishlist, in priority order:
- Back off on making various forms of tools illegal. This just makes it that much harder for the defenders.
- Impose liability on networks that do not do egress filtering.
- Oppose the
SSSCA
- Fix the DMCA
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase -
Re:As a recipient of a subpoena...At that point I told them that I was not going to do anything for them without talking to counsel, and they backed off.
You should not do anything at all without talking to the company's conusel, lest ye get a lawsuit from the accused.
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase -
Professionalizing Software is PrematureProfessionalizing software development entails:
- Codifying a set of "best practicies" that, when applied, assure a solid product.
- Codifying educational programs that teach these best practices.
- Certifying people who graduate from the educational process as "Software Engineers".
It is very nice that people are sufficiently concerned about software quality and its impact on the real world (e.g. comp.risks). But this in no way means that we actually have best practices that will assure that mediocre developers can produce working product. Wishing for it (or mandating it) will not make it so.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for Purchase -
Re:Same problem with 800 phone numbers?IANAL, but didn't Intel go with "Pentium" partly because they couldn't trademark "586?"
Yes, that's correct. What's dissapointing is that Intel didn't proceed to name the subsequent product "Hexium", leading to dorky, hard to remember product names like "Pentium III"
Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Security Hardened Linux Distribution
Available for purchase -
Re:Question - How many security options do we haveI want know if there are OTHER secure (and/or ultra-secure) version of Linux distros out there?
These are the ones I know about:
Immunix (seem to ship a secured Red Hat)
Kaladix Linux
Can't say if they are any good, I'm afraid. I'm too happy running Debian!
-- shaka -
Stackguard and Immunix
Buffer overflows, printf overflows and the like are a systematic problem. Rather than trying to fix each instance (which is still a good idea), there's an additional safety net in the form of the StackGuard compiler, and the Immunix GNU/Linux distribution. It fixes the problem systematically by checking for stack smashing.
http://www.immunix.org
The ISO images are mirrored at ibiblio.org
I really wish that Red Hat would buy them, fund them, or incorporate their changes. -
the interface is the key
the secure interface into the kernel seems to be the key to providing a well thought out way of doing security
if each module that wanted to do security a different way where to fashion its own way of interfacing then I think that only one way would end up having a chance
They seem to be using a generic interface so all credit to them (they are useing Linux Security Module)
SELinux came from the doing the same thing to Mach based systems (which is what HURD and Darwin is based on) so maybe the other projects could use this
(I am sure that Apple would not mind being on the list of US guv approved secure OS)
It seems that the NSA is actually Protecting U.S. citizens
Something it sets out in its charter amazing that all those dollars go there and very few things come out of it.
If I was a Citizen of the US I would write to my representative and commend the NSA on this project and put it in the spotlight (this often means that Projects get better funding and are less likely to disappear).
Regards
John Jones -
Re:You know what would be good?Hi guys. My roommate and I have been studying various security tools based on open source and Linux. I'm using primarily the Immunix tools including the Stackguard patches to GCC, the SubDomain patches to the kernel, and the FormatGuard patches to glibc. So far, I use either the whole Immunix OS distro which is based on an updated Redhat 7.0 (almost 7.1) or Mandrake 7.2 piecemeal upgraded with Immunix RPMs. He's primarily using Mandrake 8.0 plus the various patches at Get Rewted, which includes the kernel-based LIDS ACL patches, the portsentry IDS, the libsafe wrappers to glibc, and such.
You can even install some premade Immunix packages on top of Mandrake or Redhat. I'm successfully running apache, bind, pidentd, and openssh from Immunix conveniently on top of my good old Mandrake 7.2. I got it from the nice mirror at ibiblio and just installed them like any other package.
There is minor overlap in functionality between the two kernel-based and glibc-based subsystems, but it seems to me that the rest of these methods are all complementary. Do any of you know of a comparison between them or any analysis of them together?
Relevant criteria would include the development methods, objectives, and priorities such as the fact that as far as I know, LIDS and everything from Immunix only run on IA32.
To recap:
- either LIDS or SubDomain for kernel level ACLs for processes
- either libsafe or FormatGuard for glibc format trapping
- portsentry for IDS and port scan protection
- StackGuard to compile all your buffer overflow sensitive binaries (or use those made from Immunix)
- What else?
=== -
You know what would be good?
Awright, soapbox time!
Redhat, or someone who makes a user-oriented linux distribution, should put together standard internet services which are written in a higher-level language than C. Perhaps they will not be super high-performance, or perhaps they will not have the advanced features of sendmail or bind that most users don't use. But if they're written in a safe language like Java or O'Caml (or, to a lesser extent, scripting languages like Python) we will see the largest class of security holes vanish overnight -- buffer overflows. (Also, format-style bugs, too!)
Though I don't necessarily think this would slow them down -- even if it did, I am guessing that most people would take security over speed any day. I certainly would; hardware is cheap but my time patching and responding to incidents isn't!
I know that C is highly regarded as a systems programming language; it has many useful features in this respect. But it happens to encourage some idioms which are entirely inappropriate for network or security-critical applications. It's really not that hard to do systems programming in other languages. I kept saying this and people kept arguing with me, so I rewrote ftpd in SML . It only took me a few days; maybe a bigger team or better programmers could crank these out even faster. Here is the source code . (Also identd and fingerd ). These are not as featureful as their standard counterparts, but they are much much shorter, and buffer-overflow free.
If they can't do that because it seems like too much work (I believe moving to a more modern language would be worth it anyway), why aren't they at least compiling their default installs with stackguard ? This is so easy to use, and makes exploiting buffer overflows so much more difficult. The speed loss is imperceptible and existing code carries over.
Let's leave the last 30 years of the last century behind us and move to a world without buffer overflows! If we do this, we can perhaps spend less time worrying about security (our current practices are NOT WORKING, by the way) and start worrying about more important things!
(Yes, it's true that the sshd problem is just dumb coding and is not C's fault. However, most of the rest of this year's, and last year's big security holes come from buffer overflows. Viz: Code Red worm, BIND exploits, wu_ftpd exploits, etc...)
-
That is funny!
That is rather amusing!!!
Of course, all of this havok is just funny when you sit behind an OpenBSD firewall, running on a stackguarded version of Linux.
-
Re:Some Actual Research
Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.
Takin' care of business:- 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".
Does this release take care of the compilation problems of RH7?
That's a matter of perspectiveCan I build a 2.4 kernel with this?
We're not shipping 2.4 kernels yet, but we are working on forward porting. Note: You should not try to compile kernels with StackGuard. You either need to patch the kernel make files to turn StackGuard off, or use RPM to switch to the non-StackGuard compiler while building kernels.I would really like to use XF86 4.03
We are a server company, so we focus on server support, and not really desktop stuff. However, our engineers like to run Immunix on their desktops too, so we share what we use in our contrib directory.Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Re:Some Actual Research
Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.
Takin' care of business:- 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".
Does this release take care of the compilation problems of RH7?
That's a matter of perspectiveCan I build a 2.4 kernel with this?
We're not shipping 2.4 kernels yet, but we are working on forward porting. Note: You should not try to compile kernels with StackGuard. You either need to patch the kernel make files to turn StackGuard off, or use RPM to switch to the non-StackGuard compiler while building kernels.I would really like to use XF86 4.03
We are a server company, so we focus on server support, and not really desktop stuff. However, our engineers like to run Immunix on their desktops too, so we share what we use in our contrib directory.Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Re:Some Actual Research
Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.
Takin' care of business:- 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".
Does this release take care of the compilation problems of RH7?
That's a matter of perspectiveCan I build a 2.4 kernel with this?
We're not shipping 2.4 kernels yet, but we are working on forward porting. Note: You should not try to compile kernels with StackGuard. You either need to patch the kernel make files to turn StackGuard off, or use RPM to switch to the non-StackGuard compiler while building kernels.I would really like to use XF86 4.03
We are a server company, so we focus on server support, and not really desktop stuff. However, our engineers like to run Immunix on their desktops too, so we share what we use in our contrib directory.Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Re:Some Actual Research
Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.
Takin' care of business:- 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".
Does this release take care of the compilation problems of RH7?
That's a matter of perspectiveCan I build a 2.4 kernel with this?
We're not shipping 2.4 kernels yet, but we are working on forward porting. Note: You should not try to compile kernels with StackGuard. You either need to patch the kernel make files to turn StackGuard off, or use RPM to switch to the non-StackGuard compiler while building kernels.I would really like to use XF86 4.03
We are a server company, so we focus on server support, and not really desktop stuff. However, our engineers like to run Immunix on their desktops too, so we share what we use in our contrib directory.Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Re:Some Actual Research
Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.
Takin' care of business:- 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".
Does this release take care of the compilation problems of RH7?
That's a matter of perspectiveCan I build a 2.4 kernel with this?
We're not shipping 2.4 kernels yet, but we are working on forward porting. Note: You should not try to compile kernels with StackGuard. You either need to patch the kernel make files to turn StackGuard off, or use RPM to switch to the non-StackGuard compiler while building kernels.I would really like to use XF86 4.03
We are a server company, so we focus on server support, and not really desktop stuff. However, our engineers like to run Immunix on their desktops too, so we share what we use in our contrib directory.Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Some Actual ResearchHere's some actual research in this area:
- 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 Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
Some Actual ResearchHere's some actual research in this area:
- 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 Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase -
What is a "Derived Work"?The GPL says in 2.b:
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
For classical user-space programs written in C, this clearly means "if you link in GPL'd code, then you're derived." But there are much more ambiguous circumstances:- loadable kernel modules. Linus has said he does not view these as derived works of the kernel.
- loadable kernel modules that require a custom-hacked kernel. Linus has said that he does view these as derived works of the kernel.
- Perl modules: how intimate do you have to get with a module to be a derived work?
- .Net, the hot topic de jour: if someone provides a GPL'd
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution -
Check out Wirex's ISP software
I work for Wirex. Check out our Immunix ISP Appliance Server Software. We think our interface is very easy to use; we built in some mini-expert systems in the form of "wizards" (yes, like them
The appliance software is integrated with Immunix which is a security hardened Linux distribution. Security hardening is important in a web-managed appliance, precisely because the web interface (and the users that accompany them
-
Re:#1 problem is the studentsThis is actually pretty normal for novice instructors. Your are clearly one of the better students from your class, because you made it to grad school. Yet when you recall your experience as an undergrad, you probably assumed that you were middle of the pack (as this study).
Then you go to teach, and the top few students seem pretty decent (they're much like you) and the rest of the class seems to suck. Well, no. The rest of the class sucks as much as they ever did, only now you have to notice, because you're grading all the papers, instead of hanging out with the leet geek types.
Crispin
----
Crispin Cowan, Ph.D
Research Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
----
Research Assistant Professor of Computer Science
Oregon Graduate Institute -
It's FeedbackI've been at three different computer science schools (Waterloo, UWO, and OGI) as an undergrad, grad student, and professor. Some of these schools are great, and some not so great (no comment
What happens is at a great school, you have a strong student body. This lets the faculty run the program at a high level (teach fast, advanced content, etc.). This attracts even stronger students, forming a positive feedback loop.
At a not so great school, the students are relatively weak. This forces the faculty to teach slowly, remedial content, etc. Students may also be looking for that "quick fix carreer change", which means teaching technology (Java, JDBC, VB) instead of fundamental concepts (algorithms, data structures, abstraction). This in turn attracts more of the weaker students, forming a negative feedback loop.
So if you're hot stuff, go to a hot school. When the assignments are hard, don't be surprised. If you're more into a slack lifestyle, go to a lesser school.
Of course, teaching quality does vary. But contrary to what some other posters have said, teaching quality is not the inverse of research quality. Some research-oriented faculty are too busy to spend time on their students, while others are also truly great teachers. At small colleges, some faculty are there because they truly love to teach and are great at it, and some are there because they are lamers and a Moo U appointment is the best faculty job they could get. But my basic observation is that these variations are minor compared to the student body feedback effect.
----
Crispin Cowan, Ph.D
Research Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
----
Research Assistant Professor of Computer Science
Oregon Graduate Institute -
Re:"Bollocks" ?It's not true that doubling L1$ and adding a selection bit costs you nothing. In fact, the size of L1$ is rather limited, and cutting size in half substantially increases the miss rate. It is also fairly expensive to add selection bits.
SMT also doesn't save you from cache miss latency. Out-of-order instruction issue saves you from that.
The main advantage of SMT is that it gives computer architecture scholars something interesting to study
Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Security-hardened Linux -
BollocksIMHO, SMT is a load. Modern microprocessors are mostly cache-starved. SMT puts two processors on the wrong side of the L1$, aggrevating the cache bandwidth problem. Worse, the two processors in SMT degrade referential locality, further degrading the performance of the cache.
I'm much more interested in enhanced cache ideas like IRAM that seek to enhance performance by putting a very large L2$ on chip by combining the discrete logic circuits of the CPU and static L1$ with the capacitor cell circuits of DRAM.
Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution -
Re:DARPA - The government gets involved.
Namely, StackGuard and several of the other Immunix technologies were developed under DARPA grants.
Wil
-- -
Re:DARPA - The government gets involved.
Namely, StackGuard and several of the other Immunix technologies were developed under DARPA grants.
Wil
-- -
Re:SlashPatentsPatents appear rather quickly for that. Patent #6,000,000 was granted December 7, 1999, and #6,100,000 was granted August 8, 2000. That makes 406 patents per day. Small wonder that the prior art search is lame.
Crispin
----
Chief Research Scientist, WireX Communications, Inc.
Immunix: Hardened Linux Distribution -
Immunix 7 & FormatGuard Resist RamenUpon reviewing the excellent technical summary over at Securityfocus, we found that Immunix's FormatGuard stops all three of the exploits that Ramen uses: Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Free Hardened Linux Distribution -
Immunix 7 & FormatGuard Resist RamenUpon reviewing the excellent technical summary over at Securityfocus, we found that Immunix's FormatGuard stops all three of the exploits that Ramen uses: Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Free Hardened Linux Distribution -
Immunix 7 & FormatGuard Resist RamenUpon reviewing the excellent technical summary over at Securityfocus, we found that Immunix's FormatGuard stops all three of the exploits that Ramen uses: Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Free Hardened Linux Distribution -
Re:Infosplit web siteI e-mailed them to bitch about the blank web page, and they said they had problems this morning, but you can now get non-flash pure HTML here http://www.infosplit.com/no_flash.htm
Crispin
---
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Free Hardened Linux Distribution -
Re:Infosplit web siteIt's not just you; I also get a blank page. I even enabled Javascript, and still got a blank page.
Presumably, they have a Flash home page (I don't have a Flash plug-in, and don't want one). I don't object to web developers using Flash, but I do object to Flash being critical to content & navigation.
Crispin
----
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc.
Immunix: Free Hardened Linux Distribution -
Re:Wirex warning
Kernel compiling a bitch with Immunix OS?
Odd, but I include a patch for 2.4.0-test8 on the Immunix CD, and on our web site right here. It applies with some fuzz on 2.4.0-test12, and I'll update again on Tues for this release.
I've also been releasing this patch on the linux-kernel mailing list, as well as the stackguard mailing list for the past couple of months.
And if you have any problems with this distro, the developers are all on the stackguard mailing list, and very responsive.
As for it not being a kernel hackers special I would dispute that, as I do all of my kernel work on this os
greg k-h
greg@(kroah|wirex).com -
Wirex warningI'm salivating at 2.4-prerelease , but kernel compiling is a bitch with Immunix OS (stackguarded Redhat 6.2). Even with the recommended -mno-terminator-canary option to disable stackguard functionality and the replacement of the GNU C compiler to a non-stackguarded version, something still fucks up. I've successfully hacked kernels dozens of times but i've crossed the threshold of my patience with Immunix. Don't get me wrong - it's possibly the most robust and stable of Linux distributions, but not a kernel hackers special.
-
Not new -- and can be stopped by the compiler
Even those OSes which don't have the benefit of a security-conscious design team (um, that'd be about all of them apart from *BSD
It requires GCC patched with StackGuard, and source for the program you want to protect. (That means closed-source programs are left out in the cold... oh well.)
The resulting program runs slower, but a stack smash will usually be quickly detected. It's described at the StackGuard page.
No, it isn't a silver bullet, and yes, it can be defeated, and no, it hasn't yet been ported to anything other than x86 Linux. Still, it's better than the usual I've-just-finished-reading-teach-yourself-<foo>-i
n -ten-minutes-now-I'm-qualified-to- write-a-Linux-utility code that gets shuffled around out there. -
Annals of the History of ComputingA great place to start your investigation might be the IEEE Annals of the History of Computing.
Crispin
----
Immunix: Free, Hardened Linux Distribution
Chief Scientist, WireX -
Re:Blame the Language
This is total nonsense. In the end every compiled language gets compiled into the same x86 code that a C or C++ program gets compiled into. Therefore the problem then becomes a compiler problem. The compiler could (without any extra work on the part of the programmer!) emit code that protects against buffer overflow attacks. Indeed, the StackGuard compiler does just that.
-
Dissecting the Buffer Overflow ProblemFor a great deal of technical data on how buffer overflows work, and how to stop them, read this paper. While I appreciate the plug that Bruce gave me for StackGuard, it does seem that he has not researched this topic very well:
- Make the stack non-executable: Yes, this works, and security-conscious people will use Solar Designer's Kernel Patch to do that. It works great.
- Make the data segment non-executable: This works a whole lot less well. Too many UNIX programs depend on being able to execute code in the data segment. This is UNIX's fault, not Intel's fault.
- Use the MMU For Enforcement: Ancient Burroguhs mainframes (the 6500 IIRC) actually stored each array in a separate segment. They also ran like a dog compared to modern RISC(y) architectures. We tried the MMU approach for StackGuard in 1997, and it imposed an 8000% overhead to do it that way. Read about it in this paper.
Crispin
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX -
Dissecting the Buffer Overflow ProblemFor a great deal of technical data on how buffer overflows work, and how to stop them, read this paper. While I appreciate the plug that Bruce gave me for StackGuard, it does seem that he has not researched this topic very well:
- Make the stack non-executable: Yes, this works, and security-conscious people will use Solar Designer's Kernel Patch to do that. It works great.
- Make the data segment non-executable: This works a whole lot less well. Too many UNIX programs depend on being able to execute code in the data segment. This is UNIX's fault, not Intel's fault.
- Use the MMU For Enforcement: Ancient Burroguhs mainframes (the 6500 IIRC) actually stored each array in a separate segment. They also ran like a dog compared to modern RISC(y) architectures. We tried the MMU approach for StackGuard in 1997, and it imposed an 8000% overhead to do it that way. Read about it in this paper.
Crispin
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX -
Dissecting the Buffer Overflow ProblemFor a great deal of technical data on how buffer overflows work, and how to stop them, read this paper. While I appreciate the plug that Bruce gave me for StackGuard, it does seem that he has not researched this topic very well:
- Make the stack non-executable: Yes, this works, and security-conscious people will use Solar Designer's Kernel Patch to do that. It works great.
- Make the data segment non-executable: This works a whole lot less well. Too many UNIX programs depend on being able to execute code in the data segment. This is UNIX's fault, not Intel's fault.
- Use the MMU For Enforcement: Ancient Burroguhs mainframes (the 6500 IIRC) actually stored each array in a separate segment. They also ran like a dog compared to modern RISC(y) architectures. We tried the MMU approach for StackGuard in 1997, and it imposed an 8000% overhead to do it that way. Read about it in this paper.
Crispin
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX -
Dissecting the Buffer Overflow ProblemFor a great deal of technical data on how buffer overflows work, and how to stop them, read this paper. While I appreciate the plug that Bruce gave me for StackGuard, it does seem that he has not researched this topic very well:
- Make the stack non-executable: Yes, this works, and security-conscious people will use Solar Designer's Kernel Patch to do that. It works great.
- Make the data segment non-executable: This works a whole lot less well. Too many UNIX programs depend on being able to execute code in the data segment. This is UNIX's fault, not Intel's fault.
- Use the MMU For Enforcement: Ancient Burroguhs mainframes (the 6500 IIRC) actually stored each array in a separate segment. They also ran like a dog compared to modern RISC(y) architectures. We tried the MMU approach for StackGuard in 1997, and it imposed an 8000% overhead to do it that way. Read about it in this paper.
Crispin
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX -
Adventure ShellOnce again, Microsoft seems to have invented 20-year-old technology. The "type in-line" interface sounds exactly like the ancient "adventure shell".
Cliff is right: it is not better to type move all files beginning with the letter a to the directory called 'foo'" than to type "mv a* foo". I predict this one will be as much of a hit as Microsoft's Bob.
Crispin Cowan
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX -
Re:You are in a fashion industryI totally agree with this comment. We even have empirical evidence to support it: Java.
Java is (IMHO) the coolest popular language around, and the most popular cool language around. Before jumping on me with your favorite language, let me explain these terms:
- coolest: supporting the most wizzy features, e.g. type safety, distributed computing. Thus the list of "cool" languages is very, very large, and would include the likes of Java, Eiffel, Haskall, Scheme, ML, Hermes (my personal favorite) and the hundreds of others that the PL community has produced.
- popular: used by so many people that you can reasonably post a job ad seeking programmers with experience in that language and expect to get responses. Thus the list of "poplular" languages is relatively short. This list is nearly inclusive (I may have left out a few):
- C/C++
- Pascal
- Java
- VB (very popular, not so cool
- PERL (very popular, coolness hotly disputed)
- Python ("popularity" getting marginal here)
Now, how did Java get to be so popular? I argue that it has nothing to do with how "cool" Java is. Java could be every bit as sucky as VB, and still be nearly where it is today. Java became popular through the networking effect of being first to enable animated web pages. Yep, that's right: dancing pigs.
If Java had come out three months after animated GIFs instead of three months before, then no one ever would have heard of it.
Topical flamebait: Yes, functional programming languages are obscure and impractical. They may be "cool", but because they are hard to understand without a degree in mathematics, they have zero chance of ever becomming "popular". You will continuously see FP showing up in niche markets where correctness matters, no matter what the cost, (e.g. verifying CPUs such as the AMD/ACL2 case mentioned elsewhere, or the Hawk project being used to verify Intel processors) but you won't see FP enter the mass programming market.
Crispin Cowan
-----
CTO, WireX Communications, Inc.
Immunix: Free, Hardened Linux Distribution -
It's To Protect the MerchantThe vast majority of Internet e-commerce fraud is people buying stuff with stolen credit card numbers. When a merchant ships goods to someone and the number turns out to be bad, the merchant gets to eat the loss. This action looks like a merchant that has been burned once too often trying to protect themselves.
Crispin
--------
Crispin Cowan, CTO, WireX Communications, Inc.
Free Hardened Linux Distribution -
Re:More of Less!
Developing/studying systems that can be proved secure (buffer overflow wrapper where?)
you could have runtime protection automatically inserted by the compiler, like stackguard but it'd probably be better in the long term to use languages that have strict bounds and type checking. (modula3?)
-
Libsafe and StackGuardPerry Wagle (principle StackGuard developer) has done some analysis comparing libsafe to stackguard. Here's the short version:
- Use StackGuard when you can, because it's safer:
- Libsafe only protects selected library string functions, while StackGuard protects all potential sources of stack overflow.
- Libsafe depends on the existance of the frame pointer in the stack frame to parse/detect the stack frame. Unfortunately, the frame pointer may not be there, either because of a compile option to remove it, or because the optimizer took it out.
- Use libsafe where you cannot use StackGuard. It's better than nothing, and it can protect closed-source apps where StackGuard cannot.
My further comment on libsafe: the paper that the authors will be presenting at USENIX in June presents two forms of defense ("library intercept" and binary-rewrite (BRW)) and only the library intercept appears to be embodied in the publicly available libsafe, which is why libsafe only protects against overflows that use particular string library functions.
The BRW method is a pseudo-compiler that can transform binaries into "safe" programs by transforming the binary. It copies program onto the heap, inserting checks as it goes. The copy-to-the-heap is to make space for the additional checks. I really like the BRW method, and hope it becomes available.
If my understanding is mistaken, and BRW is actually in the distributed libsafe, please correct me.
Crispin
-------
CTO, WireX Communciations, Inc.
Immunix: Free Hardened Linux -
Libsafe and StackGuardPerry Wagle (principle StackGuard developer) has done some analysis comparing libsafe to stackguard. Here's the short version:
- Use StackGuard when you can, because it's safer:
- Libsafe only protects selected library string functions, while StackGuard protects all potential sources of stack overflow.
- Libsafe depends on the existance of the frame pointer in the stack frame to parse/detect the stack frame. Unfortunately, the frame pointer may not be there, either because of a compile option to remove it, or because the optimizer took it out.
- Use libsafe where you cannot use StackGuard. It's better than nothing, and it can protect closed-source apps where StackGuard cannot.
My further comment on libsafe: the paper that the authors will be presenting at USENIX in June presents two forms of defense ("library intercept" and binary-rewrite (BRW)) and only the library intercept appears to be embodied in the publicly available libsafe, which is why libsafe only protects against overflows that use particular string library functions.
The BRW method is a pseudo-compiler that can transform binaries into "safe" programs by transforming the binary. It copies program onto the heap, inserting checks as it goes. The copy-to-the-heap is to make space for the additional checks. I really like the BRW method, and hope it becomes available.
If my understanding is mistaken, and BRW is actually in the distributed libsafe, please correct me.
Crispin
-------
CTO, WireX Communciations, Inc.
Immunix: Free Hardened Linux