Slashdot Mirror

Up until a few months ago I was doing some sys admin work. At the time I was pretty happy with the way I set up systems, and I still think they were reasonably secure. However, articles like this have convinced me the best way to have peace of mind is to set up OpenBSD firewalls.

Is Linux more secure than other operating systems? Yes. Is it easy to shoot yourself in the foot and make the system easy to exploit? Definitely. There's an excellent article over at Security Focus that every Linux sys admin must read.

Of course if there were no users, user accounts, or traffic on the wire I'd feel even better.

For those of you saying, "Story? What story?" it can also be reached minus frames and ads, and/or while using a proxy like Internet Junkbuster. But disable JavaScript before you read the story here.

called remvbs.kix, is available at securityfocus.com. It changes registry entries for .vbs, etc. files so the default application is notepad rather than wscript or cscript.

For a moment, I was thinking of that other loophole in Kerberos...

Well, Outlook users deserve everything they get, IMO, but it's funny how I never saw this story referenced on slashdot.

According to securityfocus Linux is #2 for most announcements, with NT in the lead.

Given the number of security announcements for Linux, exactly HOW is BSD less secure?

Debian 2 2 29 5
FreeBSD 4 2 18 6
HP-UX 8 5 7 3
IRIX 26 13 8 3
Linux (aggr.) 10 23 84 30
MacOS 0 1 5 0
MacOS X Server 0 0 1 0
NetBSD 1 4 10 3
OpenBSD 1 2 4 2
RedHat 5 10 38 17
Solaris 24 31 34 6
Windows 3.1x/95/98 1 1 46 11
Windows NT 4 6 99 34

Rather than doing something creative like remvbs.kix available at securityfocus.com

Well, check out what Theo de Raadt's post to bugtraq after a FreeBSD buffer overflow was discovered.

Why not say the same for Linux?

A great example of this is if an application needs to create a temporary file. Temp directories are publically accessible, they need to be. But this means more than one user has access to them (if your OS can handle multiple users :) and this provides a place where malicious users can interfere. There's a lot of bending over backwards you can do to detect or avoid the problem, but the so-called experts seem to think that everybody should learn every trick and apply it manually. Why not provide API calls that allow a programmer to SecureFileOpen() and get a secure open file?

So, I haven't read the source for this Piranha web admin package to see why the default password Q was in there, but I suspect the coder working on it put it in as a convenience to herself for development purposes, so she could test things without having to create accounts every time. But, every app with passwords needs to do this because it is just as tedious as for every programmer. So why not build pseudo test accounts into the platform just for this purpose, rather than into the app?

is here
He basically points out that OSS is not perfect, but can be considered better than closed-source.

From the article: "simply being open source is no guarantee of security." ... Most everybody can agree with that, I think. He does an excellent job of making that point, as expected.

For those of us who suffer from the horrible HTML at securityfocus.com: the unframed article and just for good measure the unframed BugTraq Archives. Really, guys, a banner ad is fine but you've got 3/4 of the browser filled with useless flashing crap. Stop it.

From the article: "simply being open source is no guarantee of security." ... Most everybody can agree with that, I think. He does an excellent job of making that point, as expected.

For those of us who suffer from the horrible HTML at securityfocus.com: the unframed article and just for good measure the unframed BugTraq Archives. Really, guys, a banner ad is fine but you've got 3/4 of the browser filled with useless flashing crap. Stop it.

Facts:

1. IIS w/ option pack HAS a "backdoor" with "netscapeengeniersareweenies" (or something like that).
   • It allows every user with access to read all other user's .asp files. This seems not to be a bug!
   • I HAVE SEEN IT WORK.
   • So as it is would affect mostly web-hosting companies
2. BUT, Core-SDI's Gera and Beto have found a buffer overflow vulnerability.
   • It lets ANYBODY on the internet to crash a IIS with mentioned option pack (called a DOS).
   • It is demonstrated using a perl script posted on BUGTRAQ.
   • It seems HIGLY POSSIBLE to use THIS buffer overflow for arbitrary remote code execution.
   • I HAVE SEEN IT WORK.
   • So as it is affect ALL IIS w/ option pack4 on the net!!!

• I work too at Core-SDI.
• I hate lewsers talking without even trying it.
• I hate how SLASHDOT just becomes vaporware-information.
• This are the same guys who spotted RSALIB's overflows last year!
• For god's sake, even M$ admitted it!!!!

Did anyone try this exploit? I don't have my own IIS server and don't want to steal data from other servers, but if this program is proved to work than the security hole really exists.

Two dlls (dvwssr.dll and mtd2lv.dll) included with the FrontPage 98 extensions for IIS and shipped as part of the NT Option Pack include an obfuscation string that manipulates the name of requested files. Knowing this string and the obfuscation algorithm allows anyone with web authoring privileges on the target host to download any .asp or .asa source on the system. This includes users with web authoring rights to only one of several virtual hosts on a system, allowing one company to potentially gain access to the source of another company's website if hosted on the same physical machine.

If this is true, this is a vulnerability in the environment with multiple users sharing a hosting service (but not with single user as someone probably thought originally).

Anyone disproven this? Or now only vulnerabilities that don't require a local account on the system count as real?

Vuln-dev FAQ

We've been discussing this on the the vuln-dev mailing list. Here are the relevent threads:

Has anyone verified whether is is valid?

Re: dvwssr.dll (Has anyone verified whether is is valid?)

So far, concensus is that the hole, as first published by RFP, is a little misleading. It looks like a number of Frontpage servers out there may be misconfigured permission-wise, so that using his code will allow grabbing of .asp files and such off the server. Some folks think that under the same circumstances, the same could be done with a copy of Frontpage.

Now, there is a worse hole that the CoreSDI guys have found:

DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers

It's an unrelated hole, that was inspired by RFP's post.

RFP is a pretty sharp guy, so it's very likely he's onto something. It's possible that he overstated things a bit due to default permissions (which means 90% of the sites ARE vulnerable) but I wouldn't write off his work entirely. There will be more to this story Real Soon Now.

In either case, with two major problems related to the same .dll, and a huge embarassement for MS, you WILL see this file patched. :)

And let's not forget MS's word on the subject:

http://www.microsof t.com/technet/security/bulletin/fq00-025.asp

BB

Vuln-dev FAQ

We've been discussing this on the the vuln-dev mailing list. Here are the relevent threads:

Has anyone verified whether is is valid?

Re: dvwssr.dll (Has anyone verified whether is is valid?)

So far, concensus is that the hole, as first published by RFP, is a little misleading. It looks like a number of Frontpage servers out there may be misconfigured permission-wise, so that using his code will allow grabbing of .asp files and such off the server. Some folks think that under the same circumstances, the same could be done with a copy of Frontpage.

Now, there is a worse hole that the CoreSDI guys have found:

DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers

It's an unrelated hole, that was inspired by RFP's post.

RFP is a pretty sharp guy, so it's very likely he's onto something. It's possible that he overstated things a bit due to default permissions (which means 90% of the sites ARE vulnerable) but I wouldn't write off his work entirely. There will be more to this story Real Soon Now.

In either case, with two major problems related to the same .dll, and a huge embarassement for MS, you WILL see this file patched. :)

And let's not forget MS's word on the subject:

http://www.microsof t.com/technet/security/bulletin/fq00-025.asp

BB

Vuln-dev FAQ

We've been discussing this on the the vuln-dev mailing list. Here are the relevent threads:

Has anyone verified whether is is valid?

Re: dvwssr.dll (Has anyone verified whether is is valid?)

So far, concensus is that the hole, as first published by RFP, is a little misleading. It looks like a number of Frontpage servers out there may be misconfigured permission-wise, so that using his code will allow grabbing of .asp files and such off the server. Some folks think that under the same circumstances, the same could be done with a copy of Frontpage.

Now, there is a worse hole that the CoreSDI guys have found:

DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers

It's an unrelated hole, that was inspired by RFP's post.

RFP is a pretty sharp guy, so it's very likely he's onto something. It's possible that he overstated things a bit due to default permissions (which means 90% of the sites ARE vulnerable) but I wouldn't write off his work entirely. There will be more to this story Real Soon Now.

In either case, with two major problems related to the same .dll, and a huge embarassement for MS, you WILL see this file patched. :)

And let's not forget MS's word on the subject:

http://www.microsof t.com/technet/security/bulletin/fq00-025.asp

BB

Vuln-dev FAQ

We've been discussing this on the the vuln-dev mailing list. Here are the relevent threads:

Has anyone verified whether is is valid?

Re: dvwssr.dll (Has anyone verified whether is is valid?)

So far, concensus is that the hole, as first published by RFP, is a little misleading. It looks like a number of Frontpage servers out there may be misconfigured permission-wise, so that using his code will allow grabbing of .asp files and such off the server. Some folks think that under the same circumstances, the same could be done with a copy of Frontpage.

Now, there is a worse hole that the CoreSDI guys have found:

DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers

It's an unrelated hole, that was inspired by RFP's post.

RFP is a pretty sharp guy, so it's very likely he's onto something. It's possible that he overstated things a bit due to default permissions (which means 90% of the sites ARE vulnerable) but I wouldn't write off his work entirely. There will be more to this story Real Soon Now.

In either case, with two major problems related to the same .dll, and a huge embarassement for MS, you WILL see this file patched. :)

And let's not forget MS's word on the subject:

http://www.microsof t.com/technet/security/bulletin/fq00-025.asp

BB

Read this This is the actual security alert from bugtraq. I've learned not to trust slashdot's security reporting. It tends to be rather uh biased. ESR does security news. Oh yay.

Ian

The backdoor isn't as bad as ESR is implying. In order to exploit the code, the attacker needs to be given authoring privileges on the server. So this is primarily restricted to developers and only lets the attackers read .asp or .asa files.

Also the dll was present in interdev 1.0 but isn't found in later versions or in the releases on other platforms besides windows on x86. There are also questions about whether microsoft or whether the original developer vemeer technologies put it in. Therefore saying that microsoft designed this is irresponsible on the part of ESR and Slashdot.

I also have objections to ESR saying that webmasters are going be pulling out their hair over this. If the sites had upgraded to a latter version of InterDev then there's no problem. Plus, only web developers can exploit this and then only to view .asp/.asa files so its not as serious as ESR makes it out to be. Even those sites running InterDev 1.0, can get rid of the backdoor by deleting the dll since it codes for a view links feature which is not essential.

The original posting about the exploit is here

---
guillaume

Much better to go have a look at RFP's post to BugTraq.

One other comment is that M$ products frequently have reports of security holes at least as serious as this, and sometimes a lot more so. I guess this just gets the attention because it was engineered in. But, it is certainly not the only backdoor found in software. Here is a nice one here.

Parting thought, is anyone going to read this?

Much better to go have a look at RFP's post to BugTraq.

One other comment is that M$ products frequently have reports of security holes at least as serious as this, and sometimes a lot more so. I guess this just gets the attention because it was engineered in. But, it is certainly not the only backdoor found in software. Here is a nice one here.

Parting thought, is anyone going to read this?

Well, I was over at SecurityFocus and saw a listing in the headlines, "MS admits planting secret password." It's a link to the ZDNet article. Maybe the MS guy slipped and what he really meant was, "it's just a silly string some programmer put it. It does nothing bad to your system. Well, until someone makes that memo I sent out yesterday public."

Re: Cracked; rootkit - entrapment question?

There was no real final resolution to the entrapment question. There's some good arguement for both sides, though.

I've been in th is discussion about Linux vs FreeBSD firewalls on comp.unix.bsd.freebsd.misc - basically I've been using FreeBSD for assorted network torture, and had been looking at how Linux does firewalls, and they're completely different.

The eventual conclusion was that the FreeBSD 'single chain' model was more powerful than the linux model (especially with the tee ports in 4.0), and that Linux has this killer hole in the masquerading stuff. But someone did point out that a lot of this was changing under 2.4.

Any news? Any sign of tee ports (a divert port that then drops its' output back into the firewall chain)?

Dave :)

The original BUGTRAQ post is here. Taken from the post, the summary reads:

HTTP cache-control headers such as If-Modified-Since allow servers to track individual users in a manner similar to cookies, but with less constraints. This is a problem for user privacy against which browsers currently provide little protection.

Essentially, instead of giving you a cookie (which many people refuse/block) they give you a unique "cache freshness" timestamp, which your broswer nominally sends back with the conditional-GET request [see the HTTP RFC esp. sections 9.3 and 13.3.3 for description].

Note that the site would have to use the same thing linked from every page to track you, e.g. a 1x1 transparent gif. Also note that this becomes pretty useless for them if you block the REFERER header, which you should be doing any.

If this kind of thing bothers you, you should be using the Internet Junkbuster anyway.

--

We can debate the morality of nondisclosure ad nauseum. I'm more interested in engineering than morality --- and the fact of the matter is that policies that discourage full and open disclosure DO NOT WORK. They hinder the discovery of important security flaws and create an environment in which black hats have a significant advantage over white hats. Remember, the black hats don't give a damn about Mozilla's disclosure policies, and history tells us that they tend to find the problems first.

Nondisclosure has (dubious) practical benefits for tightly-guarded closed projects. Mozilla obviously doesn't qualify, and the idea that security flaws in Mozilla's open codebase can be meaningfully hidden is ludicrous.

As this is a Slashdot story, I don't trust the veracity of the claims that Mozilla is going to try to hide security information. However, if, contrary to the established best practices in the security community, they decide to go ahead with some sort of Mozilla "inner circle", they are going to give a nice black eye to Open Source's security argument.

I like MySQL. It's pretty much the 'standard', amazingly fast, and it has good support among a lot of different platforms (even M$!).
There _is_ however a bit of discussion possible about the quality of the mysql source code.
I think it will be safe to assume that MySQL is heavily optimized for speedy operation, but in my experience this sometimes has a negative influence on the clearness and security of the source code.
I have spent some time looking at the MySQL source code, trying to find vulnerabilities (sue me, i've got weird hobbies), and it isn't a pretty sight (you can see the first part of my results here, if you're interested).
Apart from the source code - MySQL has a license that's not entirely clean, as well (it looks free, but it isn't ).
Taking a look at postgresql, i see lots of clean code, features, and a better license.
I still think that MySQL is a cool database system, but from the source code and licensing scheme, I take the performance panelty, and use postgresql.

HOWEVER, why is there in each article like this also an "open source advocate" who claims that "patches from Microsoft take months to appear!", which is simply not true either!
It's a mild exaggeration, but is probably pretty close - have a read though the BugTraq archives - it is often two to three weeks after a report is handed to them before they acknowledge a problem exists, and another few weeks before a patch is released - and even then, they often seem to have "phone support for this patch as it is not regression tested" on it......
--

Even our highly clueful friends at id were caught with their hands in the cookie jar. Carmack later went on record as saying that leaving the back door in the finished product was a dumb idea, and that he regretted the decision.

Even our highly clueful friends at id were caught with their hands in the cookie jar. Carmack later went on record as saying that leaving the back door in the finished product was a dumb idea, and that he regretted the decision.

Even our highly clueful friends at id were caught with their hands in the cookie jar. Carmack later went on record as saying that leaving the back door in the finished product was a dumb idea, and that he regretted the decision.

Funnily, the Elza isn't known very well among the people which would find it useful. (It has only some name in security circles since it has been mentioned somewhere at securityfocus.)

My suggestion: Someone should post a story about the Elza here to spread the word. Any volunteers ;-) ?

After Realmedia claimed to have fixed the "bugs" in the last version, I have seen a comment that RealPlayer quietly installs the dreaded Comet Cursor with it.

If you follow BUGTRAQ, you've already seen this, but for the benefit of those who don't, the following URL leads to RealNetwork's response to this exact issue: http://www.securityfocus.com/templates/archive. pike?list=1&date=2000-03-08&msg=3.0.5.32.200003091 91004.00832cc0@mail.real.com. For those not interested in following the link, the two essential bits of the RealNetwork response are:

• "First to set the record straight, the version of Comet Cursor distributed with RealPlayer does NOT transmit GUIDs."
• "In addition, it is very important to understand that selecting the RealPlayer version with Comet Cursor is entirely optional during the download process and that Comet Cursor's existence as part of some RealPlayer bundles is clearly disclosed when you download, along with links to Comet's privacy statement."

No, I don't work for RealNetworks. Neither does my cat.

L0phtCrack, like many other software utilities, is a valuable tool. Like any other tool, it can be used for good or harm.

While it is not the case in this situation, it will be a sad day if mere possession of software is ever categorized as a crime.

At my job I am responsible for the security of a corporate network. What better way to ensure that we are relatively safe than to use the same tools that crackers will use to compromise our security?

Sites like SecurityFocus and PacketStorm are valuable resources for the full disclosure of security related issues. I hope we never lose legal access to tools because of their potential abuse.

Definately. Even if you set signed component to prompt, a Microsft signed Active X component doesn't ask you if it should install. It d/ls then just installs anyway (see bugtraq). cuartango put up a demo of this.

--locust

Read bugtraq, visit packetstorm and Security Focus regularly. Keep an eye out for weird utilization on your box, read your logs, and make sure you have as much locked down as possible. If you don't need a service, don't run it.

An Article on news.com -"Spurred by this week's widespread Web attack, President Clinton has rounded up experts, government officials and high-tech business leaders for an emergency Web security summit."

Of course, these attacks are useless, and serve as much purpose as banging your head against the wall. I'm not going to get into why people do these useless types of attacks, but it is in one way or another to get attention, or recieve recognition. Either way, whoevers doing this is could screw the rest of us over. Maybe the president, in his ultimate wisdom, along with his other attempts to gain political favor before he leaves the white house, will propose to instate IPv6. People who hear about these attacks on the news think that Yahoo (et al) were really hacked, and due to this the general public might approve. Well, these lame DoS kiddies would have really fscked us over(that is depending on your view of IPv6).

I'd like to know more about the DoS that it looks for.

There was an extensive analysis of trinoo DoS networks on Bugtraq last month. You'll learn a lot more from Security Focus" that you will from the binary or its source.

Here are some and Trinoo links.

But, dosn't anyone realize that having the source makes it easier for the trinoo coders to see how they are being detected and then modify the clients?
Anomalous: inconsistent with or deviating from what is usual, normal, or expected

This problem has been discussed a fair bit in bugtraq. The consensus was that DNS wasn't really secure using the crypt and signed message may help to prevent this but in general were not that great since netsol sometimes ignore crypt-pw and their pgp signed mail thing is often broken. Essentially if someone can forge their header so that it looks like its coming from the technical contact, it probably go through.

The bugtraq list talked about this about a month back. the original comment is here and most of the discussion on it is here

The bugtraq list talked about this about a month back. the original comment is here and most of the discussion on it is here

Jeez, where to start.... Welp, you can start by checking the Linux Documentation Project for the Linux Security How-to. If you'd like more, check out Security Focus for a b*ttload of security texts. If you got even more spare time, do a search on Google for "Linux Security"

As for books, Maximum Linux Security is pretty decent. It's a little more fun to read as opposed to the Orielly books which are more technical. Hacking Exposed is good but it covers cracking in general, not just Linux. There is plenty of information out there if your willing to look.

Good Luck
LiNT

To the best of my knowledge, people are still searching for good responses to this sort of attack.

Check out this BUGTRAQ post for an announcement about a technical get-together where people plan to brainstorm about DDoS's.

I would suggest having a look through some of the recent Bugtraq archives. These can be found at SecurityFocus. Have a look at some of the problems found in IE lately. This is & has been a problem for a long time. Here's a Hotmail example. There are postings regarding similar problems with most of the web based email services. Active scripting causes more problems than javascript.

It has been recommended that you disable all scripting for security reasons for a while now. It's very good practice.

I would suggest having a look through some of the recent Bugtraq archives. These can be found at SecurityFocus. Have a look at some of the problems found in IE lately. This is & has been a problem for a long time. Here's a Hotmail example. There are postings regarding similar problems with most of the web based email services. Active scripting causes more problems than javascript.

It has been recommended that you disable all scripting for security reasons for a while now. It's very good practice.

I would suggest having a look through some of the recent Bugtraq archives. These can be found at SecurityFocus. Have a look at some of the problems found in IE lately. This is & has been a problem for a long time. Here's a Hotmail example. There are postings regarding similar problems with most of the web based email services. Active scripting causes more problems than javascript.

It has been recommended that you disable all scripting for security reasons for a while now. It's very good practice.