Slashdot Mirror

It's hard to be impressed with "paraoid-level security" when one has dealt with OpenSSL and OpenSSH have had fifty three vulnerabilities between the two of them over the past five years: CVE-2000-0525, CVE-2000-0887, CVE-2000-1169, CVE-2001-0361, CVE-2001-0529, CVE-2001-0816, CVE-2001-0872, CVE-2001-1029, CVE-2001-1380 , CVE-2001-1382, CVE-2002-0059, CVE-2002-0083, CVE-2002-0575, CVE-2002 -0639, CVE-2002-0640, CVE-2002-0765, CAN-1999-0661, CAN-2000-0535, CAN -2001-0572, CAN-2001-1459, CAN-2001-1483, CAN-2001-1507, CAN-2003-0190, CAN-2003-0386, CAN-2003-0682, CAN-2003-0693, CAN-2003-0695, CAN-2003-0786, CAN-2003-0787, CAN-2004-0175, CAN-2004-1653, CAN-2004-2069, CVE-1999-0428, CVE-2001-1141, CVE-2003- 0078, CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0657, CAN- 2002-0659, CAN-2002-1568, CAN-2003-0131, CAN-2003-0147, CAN-2003-0543, CAN-2003-0544,

It's hard to be impressed with "paraoid-level security" when one has dealt with OpenSSL and OpenSSH have had fifty three vulnerabilities between the two of them over the past five years: CVE-2000-0525, CVE-2000-0887, CVE-2000-1169, CVE-2001-0361, CVE-2001-0529, CVE-2001-0816, CVE-2001-0872, CVE-2001-1029, CVE-2001-1380 , CVE-2001-1382, CVE-2002-0059, CVE-2002-0083, CVE-2002-0575, CVE-2002 -0639, CVE-2002-0640, CVE-2002-0765, CAN-1999-0661, CAN-2000-0535, CAN -2001-0572, CAN-2001-1459, CAN-2001-1483, CAN-2001-1507, CAN-2003-0190, CAN-2003-0386, CAN-2003-0682, CAN-2003-0693, CAN-2003-0695, CAN-2003-0786, CAN-2003-0787, CAN-2004-0175, CAN-2004-1653, CAN-2004-2069, CVE-1999-0428, CVE-2001-1141, CVE-2003- 0078, CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0657, CAN- 2002-0659, CAN-2002-1568, CAN-2003-0131, CAN-2003-0147, CAN-2003-0543, CAN-2003-0544,

It's hard to be impressed with "paraoid-level security" when one has dealt with OpenSSL and OpenSSH have had fifty three vulnerabilities between the two of them over the past five years: CVE-2000-0525, CVE-2000-0887, CVE-2000-1169, CVE-2001-0361, CVE-2001-0529, CVE-2001-0816, CVE-2001-0872, CVE-2001-1029, CVE-2001-1380 , CVE-2001-1382, CVE-2002-0059, CVE-2002-0083, CVE-2002-0575, CVE-2002 -0639, CVE-2002-0640, CVE-2002-0765, CAN-1999-0661, CAN-2000-0535, CAN -2001-0572, CAN-2001-1459, CAN-2001-1483, CAN-2001-1507, CAN-2003-0190, CAN-2003-0386, CAN-2003-0682, CAN-2003-0693, CAN-2003-0695, CAN-2003-0786, CAN-2003-0787, CAN-2004-0175, CAN-2004-1653, CAN-2004-2069, CVE-1999-0428, CVE-2001-1141, CVE-2003- 0078, CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0657, CAN- 2002-0659, CAN-2002-1568, CAN-2003-0131, CAN-2003-0147, CAN-2003-0543, CAN-2003-0544,

It's hard to be impressed with "paraoid-level security" when one has dealt with OpenSSL and OpenSSH have had fifty three vulnerabilities between the two of them over the past five years: CVE-2000-0525, CVE-2000-0887, CVE-2000-1169, CVE-2001-0361, CVE-2001-0529, CVE-2001-0816, CVE-2001-0872, CVE-2001-1029, CVE-2001-1380 , CVE-2001-1382, CVE-2002-0059, CVE-2002-0083, CVE-2002-0575, CVE-2002 -0639, CVE-2002-0640, CVE-2002-0765, CAN-1999-0661, CAN-2000-0535, CAN -2001-0572, CAN-2001-1459, CAN-2001-1483, CAN-2001-1507, CAN-2003-0190, CAN-2003-0386, CAN-2003-0682, CAN-2003-0693, CAN-2003-0695, CAN-2003-0786, CAN-2003-0787, CAN-2004-0175, CAN-2004-1653, CAN-2004-2069, CVE-1999-0428, CVE-2001-1141, CVE-2003- 0078, CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0657, CAN- 2002-0659, CAN-2002-1568, CAN-2003-0131, CAN-2003-0147, CAN-2003-0543, CAN-2003-0544,

Umm IIS6 has less exploits and no unpatched vunerabilities compared to Apache 2.0.x which still has unpatched vunerabilities.

Have you looked at the apache security vulnerabilities? There was only one in 2005, and here is the link to the cve:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2004-1387

It's not even about apache, it's about a third party apache-utils. That package isn't even part of my distro. i have no such script called check_forensics.

The only other unpatched issue with apache is this one:

http://secunia.com/advisories/11176/

Which is rated as non-critical. And it says it's confirmed for 2.0.46 and lower. The latest version is 2.0.54.

Regardless IIS6 & Apache have both been really good. A lot of IIS's reputation comes from IIS5, and let's face it, it is really well deserved. IIS5 is horribly unsecure without first running the lockdown tool, which not all Win Admin's do!

Can someone explain why this zlib buffer overflow is only considered as a candidate for inclusion in the CVE list?

Has it not been completely verified, or is there just a lot of red-tape involved in being accepted by the CVE board?

I'm running RHN alert notification on Fedora Core 3, and my version of zlib has already been updated with a patch for CAN-2005-2096, the zlib overflow bug.

It's interesting to read about these as they occur, but it's a nice feeling that my operating system is so well taken care of. Too bad that all personal computers aren't set up for this kind of timely response. I wonder about those millions of library computers, home PCs, small business computers, and other institutional setups where no one even understands the concept of an update, let alone regularly runs the Windows "security" update program.

Another reason to use Linux!

Such as this one?

Lynx has had vulnerabilities in the past, too - this one, for example. The only *really* safe way to browse is probably to use telnet, but I'm not sure you can even call that "browsing" anymore.

One of the better worm analysis papers I've read was "Reflections on Witty" by Nicholas Weaver and Dan Ellis (of MITRE), published in the June 2004 issue of ;login, the Usenix magazine.

Rather than a dissection of the worm itself, the authors give a detailed analysis of the author/attacker of Witty.

Some insights about the worm author that Weaver and Ellis proposed:

• he was a fairly proficient programmer - there were no significant bugs in the code of the worm, he knew how to program x86 assembly and access the Windows API, he implemented a stack-overflow attack, and most importantly, he constructed a payload that was malicious to the host, but didn't significantly slow the worm's spread.
• he was quite clever at what he did - randomly padded packet sizes, randomized the destinations and port numbers, and he seeded the worm (rather than start at a single location, the worm started out from 110 different victims) -- prior to this no one had significantly seeded their worms
• he wrote compact code, Witty consists of 177 x86 instructions in 474 bytes (the rest is the buffer overflow and padding); with 177 instructions, he was able to construct routines to cleanup from the overflow attack, seed the RNG, propagate the worm, and execute the malicious payload (Witty slowly overwrites disks on the infected hosts until the machine crashes)
• he worked quite fast; the stack overflow in the ISS BlackIce products was published on March 18, 2004. Witty was released on March 19, 2004, less than 48 hours after the security advisory was published by eEye; it is possible that he knew of the vulnerability when eEye notified ISS on March 8, 2004, but the paper goes into why this is unlikely
• he probably tested the worm before he released it (cf. the lack of major bugs); this combined with the fact that he seeded on 110 hosts, means that he had access to a wide array of compromised machines -- it probably means he has access to the "hacker underground", to gain access to these machines in such a short time frame

The authors' conclusion is somewhat alarming, they reason that Witty represents a new generation of virus/worm authors: motivated, skilled and malicious individuals who are experts at what they do.

I don't know about "breaking out" of a chroot, but 2.4.29 has local root vulnerabilities in it, e.g.:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name= CAN-2005-1263

Remote root vulnerabilities are rare because most things aren't running as root, but you probably have quite a wide footprint of daemon software running as a normal user, so there's a good chance there are vulnerabilities to be had there. Combine that with one of the regularly discovered local root exploits and you can do whatever you like.

I'm not saying this isn't a hole and that it shouldn't be fixed, but I am saying that you would need to be really very paranoid about your security to be taking notice of the potential for stealing your RSA keys through complex cache mathematics :)

This vulnerability doesn't cause the payload to not be encrypted, it's a means of figuring out how to decrypt them without knowing the key.

Of course, the whole thing relies on you having message authentication (hmac-md5 or hmac-sha1) off. Something which was already known to be a bad idea.

With authentication off, someone can twiddle bits in the packet (without knowing their original state, but they can predictably flip a specific bit). From that, you look at the reply. If you do this enough times to fields that have predicable behavior, such as the TCP sequence number, you can gather enough information to figure out the encryption state and decrypt some of the packets in the stream.

To me, this whole thing is a gigantic "DUH". Almost crypto protocol which doesn't have good integrity protection is likely to be attacked this way. It's been done dozens of times.

Weaknesses using CRC32 as a cryptographically secure integrity check is how the classic SSH crc-compensation attack worked:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999 -1085

Lack of integrity is part of why VTUN is considered insecure to the point of being broken:
http://off.net/~jme/vtun_secu.html

This kind of attack is blatantly obvious. It's been written about many times and demonstrated against many different protocols in the past. It's why nearly every book on IPSEC I've seen warns that if you don't use a MAC, someone will break your crypto.

The only difference is that before it was a obvious theoretical weakness. Now it's one that's been demonstrated in practical application.

The first computerized system with a GUI was SAGE, the air defense system. This had CRTs and pointing devices in 1958. The pointing device was a light gun, and it really looked like a gun. This was appropriate, because, in the appropriate modes, pulling the trigger on the light gun could launch a surface to air missile.

There were a number of graphical CAD systems well before the PARC effort. Sutherland's Sketchpad, in 1963, was the first prototype. The General Motors DAC-1, in 1964, was the first commercial one.

The PLATO system, a very early computer-based instruction system, was demoed in 1960, but, like most of the other systems of that era, tied up a whole mainframe for one user. Plato was gradually scaled up - by 1967, there were special plasma flat panel displays (red only) and time-shared access.

So by the early 1970s, there were quite a few GUI projects that worked. They just cost too much.

Getting the cost down took a while. The early minicomputer-based workstations like the Alto were in the $25-50K range. The UNIX workstations of the early 1980s (Sun, Apollo, PERQ) were in that price range. The original Apple Lisa, a good but expensive machine, cost $10K. The original cost-reduced Macintosh was around $2500, and, lacking a hard drive, it really wasn't very useful. Not until the Macintosh was built up to a reasonable hardware level (512K and a hard drive) could you really get any work done with it.

By then, in the late 1980s, the hardware was finally ready. You could get a megabyte of memory, a bit-mapped display, a reasonable CPU, and a hard drive in a desktop box for under $3K. At which point Microsoft moved into the field.

> Just because it's running IIS 5 doesn't mean it has 14 holes automatically

Of course it doesn't.

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ii s+5.0

Their PIX firewall is no competition to the other popular vendors. It lacks both the performance and features of Netscreen/Junpier and has a shoddy security record.

Their IDS is less sensitive than Snort and its VMS manager software is slow, hideously bloated and buggy.

For several years, Cisco have been promoting an insecure combination of IPSEC shared-secret with xauth. Despite being documented as dangerous on their own website, it was still the taught and recommended way of configuring "convenient" secure remote access VPNs. Only in the last six months have they fixed this.

Their NAC/self-deluding-network initiative is broken as proposed. All enforcement is performed in the wrong place: routers off in the edge of the network. Right now, there is no way to deploy NAC on a switch or even a MSFC.

Cisco need to stop their marketing droids from directing their product development and get back to competing on technology.

I wonder though why Microsoft didn't update to a newer version of libPNG when the vulnerability was addressed last August.

-Lucas

The vulnerability is described in MS05-009 which refers to CAN-2004-0597. This is a buffer overflow in libpng which was fixed in early August last year. So Microsoft needed six months to fix a publicly known vulnerability.

The system was called the Broadcast News Navigator, and more information is here:

http://www.mitre.org/tech/itc/g061/bnn/mmbnn.html

and

http://www.mitre.org/tech/itc/g061/bnn/mmcomputing .html

The system was called the Broadcast News Navigator, and more information is here:

http://www.mitre.org/tech/itc/g061/bnn/mmbnn.html

and

http://www.mitre.org/tech/itc/g061/bnn/mmcomputing .html

Pardon me for being insistent, but "openoffice.org" is a Web address, not a name. If the company that makes it doesn't want their customers to call it "Open Office," they should change the name. (They should probably change the name in any case. "Open Office" doesn't exactly stir the soul.)

That's not being insistent, it's being stupid. OpenOffice.org is the name of the software. The original poster was correct, you tried to correct him but looked like an idiot because you were wrong and then I corrected you. It's a very simple sequence of events; do try and keep up. As for what you think of the name, nothing you've posted so far inspires me to assign any value to your opinion.

Numbers.

A meaningless non-response with nothing to back it up, almost certainly indicating that you have no basis for your opinion. This is unsurprising.

No, it was supposed to be illustrative. Reading comprehension much?

Illustrative of what? That you don't hire competent people? That you change your hardware and software platform whenever you change IT personnel? It's certainly not illustrative of anything regarding open source software.

> We use open source software because we like the support, reliability and licensing freedom.

How odd. Because it has none of those three things.

I don't normally go in for personal attacks but you're really not a very honest person, are you? Starting from the end:

For you to claim that open source software doesn't provide licensing freedom is either stupid or dishonest. Since you're apparently capable of operating a computer with at least minimal competency I find it difficult to believe that you could be stupid enough to believe what you said. So you've apparently lying. Unfortunately you chose to lie about a subject that the Slashdot audience understands reasonably well so you're not going to get very far.

As for reliability, there are plenty of studies that show the reliability of open source.

And finally, support. I don't think this will be news to anyone except (perhaps) you but paid support is available for open source software. Linux is supported by distributions such as Redhat and Novell, Apache & Tomcat are supported by companies like JBoss and Samba is supported by a truly huge list of companies in many countries. As another poster pointed out, OpenOffice.org has commercial support available from companies like Blue Point

You shouldn't bother replying to this, but if you do be sure to bring some facts to back up your position. Your blind assertions do not impress.

Well, between this announcement and Microsoft's latest security fixes (including a fix for the HTML Help cross-scripting vulnerability, yay!), I think I'll finally be able to persuade them.

No, OS X isn't perfectly secure, nor is it Free -- both important considerations. But it will help keep my parents from inadvertantly polluting the Internet with spam, viruses, and trojans, and do a lot better job of it than Windows.

Try http://www.debian.org/security/. It's more than just a line in your sources.list.

and the fixes?

Yep, that's there too. For example, this page about an xpdf problem has date reported, links to the bug track which document the problem, the CVE page, itself what you are looking for, and packages to fix the problem. XPDF? Bummer, I had no idea, but I'm glad it got fixed in the upgrade last week.

Practically, you drop the appropriate line into your /etc/apt/sources.list file:

deb http://security.debian.org stable/updates main contrib non-free
deb http://security.debian.org testing/updates main contrib non-free

and security update will happen at every apt-get update, apt-get upgrade you do. Asking to add this line has been part of the installation for a long time. It may be the only thing you need for your sources.list file.

The Sarge net install CD gets all of it's packages straight off the web and does so before starting services that might be exploited. This makes every install as current as it can be and the whole process relatively secure. That's the bottom line, right?

Compare that to the typical Windoze wipe and reload with the "orignial" years old CD that came with the computer and M$'s aging codebase and you start to see how the free software development and distribution methods are vastly superior to closed source.

It is worth noting that the Content-Length security problem is in mod_proxy, not in the main daemon.

See CAN-2004-0492 for details.

What degree of vulnerability does each security update affect (serious, critical, not that big a deal)? What's the attack vector? What are the workarounds? How do these changes affect other apps that may rely on them?

Name
CAN-2003-0020 (under review)

Description
Apache does not filter terminal escape sequences from its error logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences.

References
VULNWATCH:20030224 Terminal Emulator Security Issues
URL:http://archives.neohapsis.com/archives /vulnwatch/2003-q1/0093.html
BUGTRAQ:20030224 Terminal Emulator Security Issues
URL:http://marc.theaimsgroup.com/?l=bugtra q&m=104612710031920&w=2
XF:apache-esc-seq-injecti on(11412)
URL:http://www.iss.net/security_center/ static/11412.php

Phase
Proposed (20030317)

Votes
ACCEPT(2) Cole, Baker
MODIFY(1) Cox
NOOP(3) Wall, Green, Christey

Comments
CHANGE> [Cox changed vote from REVIEWING to MODIFY]
Cox> This issue affects Apache 1.3.27, Apache 2.0.45 and earlier,
as well as possibly later versions (since it's not fixed by
ASF yet)
Cox> ADDREF REDHAT:RHSA-2003:139
Christey> MANDRAKE:MDKSA-2003:050
(as suggested by Vincent Danen of Mandrake)
Christey> REDHAT:RHSA-2003:243
Christey> BUGTRAQ:20040330 TSLSA-2004-0017 - apache
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 066914830552&w=2
Christey> APPLE:APPLE-SA-2004-05-03
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 369640424244&w=2
Christey> BUGTRAQ:20040512 [OpenPKG-SA-2004.021] OpenPKG Security Advisory (apache)
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 437852004207&w=2
Christey> SLACKWARE:SSA:2004-133
URL:http://www.slackware.com/security/viewer.php? l=slackware-security&y=2004&m=slackware-security.5 29643
TRUSTIX:2004-0027
URL:http://www.trustix.org/errata/2004/0027
Christey> MANDRAKE:MDKSA-2004:046
URL:http://www.mandrakesecure.net/en/advisories/a dvisory.php?name=MDKSA-2004:046
Christey> BUGTRAQ:20040526 [ GLSA 200405-22 ] Apache 1.3: Multiple vulnerabilities
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 559521611694&w=2
Christey> HP:SSRT4717
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 731648532365&w=2

What degree of vulnerability does each security update affect (serious, critical, not that big a deal)? What's the attack vector? What are the workarounds? How do these changes affect other apps that may rely on them?

Name
CAN-2003-0020 (under review)

Description
Apache does not filter terminal escape sequences from its error logs, which could make it easier for attackers to insert those sequences into terminal emulators containing vulnerabilities related to escape sequences.

References
VULNWATCH:20030224 Terminal Emulator Security Issues
URL:http://archives.neohapsis.com/archives /vulnwatch/2003-q1/0093.html
BUGTRAQ:20030224 Terminal Emulator Security Issues
URL:http://marc.theaimsgroup.com/?l=bugtra q&m=104612710031920&w=2
XF:apache-esc-seq-injecti on(11412)
URL:http://www.iss.net/security_center/ static/11412.php

Phase
Proposed (20030317)

Votes
ACCEPT(2) Cole, Baker
MODIFY(1) Cox
NOOP(3) Wall, Green, Christey

Comments
CHANGE> [Cox changed vote from REVIEWING to MODIFY]
Cox> This issue affects Apache 1.3.27, Apache 2.0.45 and earlier,
as well as possibly later versions (since it's not fixed by
ASF yet)
Cox> ADDREF REDHAT:RHSA-2003:139
Christey> MANDRAKE:MDKSA-2003:050
(as suggested by Vincent Danen of Mandrake)
Christey> REDHAT:RHSA-2003:243
Christey> BUGTRAQ:20040330 TSLSA-2004-0017 - apache
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 066914830552&w=2
Christey> APPLE:APPLE-SA-2004-05-03
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 369640424244&w=2
Christey> BUGTRAQ:20040512 [OpenPKG-SA-2004.021] OpenPKG Security Advisory (apache)
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 437852004207&w=2
Christey> SLACKWARE:SSA:2004-133
URL:http://www.slackware.com/security/viewer.php? l=slackware-security&y=2004&m=slackware-security.5 29643
TRUSTIX:2004-0027
URL:http://www.trustix.org/errata/2004/0027
Christey> MANDRAKE:MDKSA-2004:046
URL:http://www.mandrakesecure.net/en/advisories/a dvisory.php?name=MDKSA-2004:046
Christey> BUGTRAQ:20040526 [ GLSA 200405-22 ] Apache 1.3: Multiple vulnerabilities
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 559521611694&w=2
Christey> HP:SSRT4717
URL:http://marc.theaimsgroup.com/?l=bugtraq&m= 108 731648532365&w=2

The silence over the recent security updates (and the resulting mocking of one-paragraph summaries Apple then decided to release) has lost a lot of people's respect.

The issue affects cvs +pserver. It's listed with references at Mitre.

There are plenty of open source solutions for setting up a mesh network, some of which are covered here.

Thomas Krag & Co. also maintain a wiki that you may find useful.

Mobile Mesh runs in user-land and is covered by the GPL. It seems to get the best reviews.

-- Douglas

I gather mobilemesh is not an ideal solution, but it is good enough for neighbourhood sized networks, until the state of the art advances, producing a better successor.

Choice quote (emphasis added):
"The main conclusion of the analysis was that FOSS software plays a more critical role in the DoD than has generally been recognized. FOSS applications are most important in four broad areas: Infrastructure Support, Software Development, Security, and Research. One unexpected result was the degree to which Security depends on FOSS. Banning FOSS would remove certain types of infrastructure components (e.g., OpenBSD) that currently help support network security. It would also limit DoD access to--and overall expertise in--the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks. Finally, it would remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack . Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks."

Overall, MITRE carries much more credibility in the government than some apparently politically and economically motivated "thinktank"

Apple tries to publish the CVE number for every vulnerability it patches. Visit CVE to read a full technical rundown.

So, I guess the point is that Apple respond to holes and you're too lazy to look them up? :)

The original poster is not correct when claiming Internet Explorer has a problem. This time it's a hole in the so called "Local Security Authority Subsystem Service" that's causing problems.

See this and this for more details.

Everyone knows not to use windows products until after at least 1 service pack, this is an old problem that was fixed with service pack 1.

Uh... what?

Buffer overflow in certain Active Directory service functions in LSASRV.DLL of the Local Security Authority Subsystem Service (LSASS) in Microsoft Windows NT 4.0 SP6a, 2000 SP2 through SP4, XP SP1, Server 2003, NetMeeting, Windows 98, and Windows ME, allows remote attackers to execute arbitrary code by causing long debug entries to be generated for the DCPROMO.LOG log file. (emphasis mine)

• Mutt
• Pine
• Mozilla
• imap-2002b Pine , Evolution, Mozilla, Eudora via imap

If you look up the specifics of the vulnerability CAN-2003-0542, it's something to do with mod-alias/mod-rewrite. If someone creates a bunch of rewrite rules in a .htaccess or httpd.conf that match 9 "captures", it can trigger a boundary condition/overflow that can cause bad things to happen.

The Department of Defense already developed a study on the application of open source:

http://www.mitre.org/work/tech_papers/tech_papers_ 01/kenwood_software/index.html

MITRE has been working on TrIM for a while.
Read about it here. Sorry if it's marketdroidish, it was the first link that I could find.

On your specific points:

• Agreed that NT has access controls on every object. However they are not visible and not used very much by end users and administrators. The UNIX ones are simple and very easy to understand. Here you have the choice between complicated (you do know the difference between discretionary and inherited rights filters?) and pervasive (every object) versus simple and pretty much only on files (which almost every OS object is anyway).

  Many (if not most) Windows programs get it wrong. Heck even Microsoft has been released games that can only be played if logged in as administrator.

  Linux does let you do delegation, but that is mostly left as a user space implementation issue. That is the purpose of setuid/setgid, group memberships, sudo etc.

• The Windows acceditation is a crock. It is in a non-networked environment with no floppy disk or CD drive. Show me anyone who deploys that way. Here are some relevant articles: Win2K evaluation IBM/Suse evaluation. I have one specific question: if the Windows architecture is so fantastic, why did the NSA choose Linux to acheive their goals? Why did Microsoft claim that fundamental design flaws in Windows were the reason they couldn't release the Windows code? (And we won't even go into the ability of any process in a desktop session being able to send messages to any other process which is probably the flaw Microsoft alludes to).
• And you deploy Microsoft patches immediately without worrying that they will break the other products you run and use? You can get Linux advisories from whatever distro you use. There are also services like CVE. At least with Linux you can choose to fix things yourself. With Microsoft, you are stuck with whatever amount of time and problem severity they determine. If they don't want to fix something for 6 months, there is nothing you can do about it.
• SCE is nice, but is only needed because the whole OS has so many places where ACLs are applied. And it doesn't do things like registry access control (you have to use regedit) or the filesystem. So you do have to use a number of tools, and understand everything. In Linux you have to understand chmod. In either case, a clueless admin will do way more harm than the OS you picked to run.

I don't know if that is what you're searching for, but MITRE corporation did a nice case study about OSS for the DOD, you can find it there: http://www.mitre.org/work/tech_papers/tech_papers_ 01/kenwood_software/index.html

Conectiva routinely releases patches that are months late.

Take, for instance, the most recent, CLA-2003:762, released October 14 for a glibc bug from August 14.

My all-time favorite, however, is CLA-2003:628, released in April 2003 for a vulnerability in vixie cron announced in March 2001!

So, if you count Conectiva, Gates is probably right about it taking a couple of weeks on average, even if everyone else does it in 24 hours.

760 days for Conectiva + 1 day each for 50 other distributions is about 16 days, on average.

Conectiva routinely releases patches that are months late.

Take, for instance, the most recent, CLA-2003:762, released October 14 for a glibc bug from August 14.

My all-time favorite, however, is CLA-2003:628, released in April 2003 for a vulnerability in vixie cron announced in March 2001!

So, if you count Conectiva, Gates is probably right about it taking a couple of weeks on average, even if everyone else does it in 24 hours.

760 days for Conectiva + 1 day each for 50 other distributions is about 16 days, on average.

OpenSSH_3.4p1+CAN-2003-0693

They're behind by one. See CAN-2003-0695.

I can't speak for the folks in the .mil area, though I know quite a few that have went into companies like Mitre after leaving the service. I got picked up right out of college into .gov,--- things were definitely behind the times. AOS/VS on the servers and MS-DOS at the desktop. I worked as a sysadmin through SCO Unix, Win3.11, NT4.0 and Exchange 5.5. Over the first six years I saw around 40+ states of the US, as well as Guam, Saipan and Japan - a good road trip all on the taxpayers dime. At the same time, the pay was good at the end but looooow for the first couple years. The last two have been the best as we are all Windows 2000/ XP on Dell desktops and a mix of Netware, Wintel, Solaris and yes, some Red Hat on the server side. Some of the stuff about .gov IT is true, laziness, lack of security, blah, blah, blah. I am in my mid 30s (the youngest on an IT staff of seven) but trying to improve the situation for my end users and they see that. Compared to the sysadmin that left that was in his 50s and read the newspaper all day- I am the man. You won't get rich doing .gov IT, but it is stable and can be rewarding.

BTW, all the software described below either is or will be free.

Now, OVAL is in SQL right now, but we're working on an XML translation mechanism. The SQL is nice because it's intensely readable and writable by humans and also because it can be used to query a database of system attributes. That database leads to a technology called QNA, formerly known as Outpost.

QNA involves a system whereby which host-based agents insert data about the system into a SQL database which you can then query. The host-based agents give you far better accuracy than a network vulnerability scanner like Nessus. The database gets you massive scalability, so that you can check a thousand hosts in pretty reasonable times. (Nessus still rocks, btw. Go Renaud!)

BTW, you don't need QNA to make this useful. You can run an OVAL query interpreter on a single host to check a vulnerability. This query interpreter already exists for Windows -- we'll build it for Linux too.

Anyway, check it all out. oval.mitre.org.

- Jay

For those interested in open standards for vulnerability assessment, you should check out the Open Vulnerability Assessment Language (OVAL - http://oval.mitre.org/). OVAL provides assessments that DO NOT PERFORM THE ACTUAL EXPLOIT but rather specify logical conditions on the values of system characteristics and configuration attributes to characterize which systems are susceptible to a given vulnerability.

The assessments use SQL syntax but there is an XML version coming soon.

The Open Security Project (OpenSec - http://www.opensec.org/) is also developing a similar standard. The Advisory and Notification Markup Language (ANML - http://www.opensec.org/anml/) is not only working on assessment but an entire advisory format in XML.

But it's alredy licensed by the MITRE corp. :-) http://www.mitre.org/news/releases/02/transclick08 _14_02.html, it's called Translingual Instant Messaging (TrIM).

I did. It was running Apache 1.3.26. See this advisory for details. Blame this provider for shoddy security. Oh well, chalk me up for two points for hitting a Linux box!

The Mobile Mesh Routing Protocol (MMRP) is a robust, scalable, andefficient mobile adhoc routing protocol based upon the "link state" approach. A node periodically broadcasts its own Link State Packet (LSP) on each interface participating in the protocol. LSP's are relayed by nodes, thus allowing each node to have full topology nformation for the entire adhoc network. From its topology database, a node is able to compute least cost unicast routes to all other nodes in the mobile adhoc network.

All the nodes on my WiFi network talk in ad-hoc mode, using Mobile Mesh for routing (including the Zaurus). Traffic is then encrypted with IPSec and authenticated against my LDAP server.

As a result as long as I am in range of any one of my nodes (not a difficult thing in this house) I get a good signal - the cloud covers most of the garden too. And all without dropping a bundle on network engineers, antennas, amplifers or anything else.

But then again what do you expect of someone who works for MSN? Routing? Isn't that the thing you do with some kind of workmans tool?

Since the USSR wound down, GEODSS has also been used for finding near-earth asteroids. A few objects show up every month. Here's the list for December, 2002.

MIT's Lincoln Labs also operates an automated skywatch.

Here's an image from GEODSS. The objects that show as streaks are moving relative to the starfield.

If it's out there, one of these systems will pick it up within a few days.