Slashdot Mirror

Forged headers are only possible because of bad code. This has been a recognised problem for years now, I read an article 5 years ago about the flawed code, and that it should be fixed (sendmail2 from memory).

Is this a troll, or are you just really stupid?

That fact that mail headers are forgeable is due to the nature of SMTP, not anyone's "bad code". While programs like sendmail are certainly poorly written, that has nothing to do with forgery. Moron.

Go read this, or perhaps RFC 821/2821. But whatever you do, get a damned clue.

Just in case anyone's wondering, this is the same hole reported on Slashdot yesterday and reported in this CERT advisory.

I mention this because the FreeBSD posting doesn't explicitly mention which version of Sendmail this affects, but it does link to the CERT article.

I'm sure I've been portscanned a couple times, but as far as I can find there have been no vulnerabilities found for my version of Cyrus. I found a CERT Vulnerability Note which talks about version 2.1.10, but I have 2.1.12 (from Debian unstable).

So, make sure there are no exploits for your IMAPd and hope for the best... :-)

Cheers,

Costyn.

Note that isn't one of Slashdot's conspiracy theories. If you report something to CERT/CC for free, they sell it to their subscribers.

Unfortunately, this process is not defined in a way that is transparent for those who contact CERT/CC. I've seen conflicting reports regarding the question whether this sharing is mandatory or optional, implicit or explicit. Not surprisingly, the CERT/CC website is not very helpful:

We also send vulnerability information to others who can contribute to the solution and with whom we have a trusted relationship. In addition to vendors, this may include experts in the community, CERT/CC sponsors, and members of the Internet Security Alliance (including private sector organizations). We also send vulnerability information to sites that are part of critical infrastructures that we believe are at risk.

I've been suprised out how recently Oracle "Unbreakable" ads have been running (here in the US). I'm not in the UK at the moment, but given that Oracle products got thumped anew pretty quickly after Oracle decided to brag about being "unbreakable" I'm surprised nobody has asked the ASA to jump on it.

After all, it's not exactly an infrequent problem.

I've been suprised out how recently Oracle "Unbreakable" ads have been running (here in the US). I'm not in the UK at the moment, but given that Oracle products got thumped anew pretty quickly after Oracle decided to brag about being "unbreakable" I'm surprised nobody has asked the ASA to jump on it.

After all, it's not exactly an infrequent problem.

I've been suprised out how recently Oracle "Unbreakable" ads have been running (here in the US). I'm not in the UK at the moment, but given that Oracle products got thumped anew pretty quickly after Oracle decided to brag about being "unbreakable" I'm surprised nobody has asked the ASA to jump on it.

After all, it's not exactly an infrequent problem.

I guess they were just trying to out-do the IIS hole.

Ah well ... there's always "linux single" ... :)

A joke, but just so other people are clear other segments of memory are vulnerable to overflows as well:

- .bss section: for uninitialized data. In this exploit I smashed a buffer in .bss space that ended up overwriting a function pointer in the .dtors section (IIRC, this was many years ago). Upon exit this function was called and ran a shell.

- .data section: for initialized data. In this one I was able to overflow a set of character pointers in the xlock (screensaver) program. By overflowing them with the address of the /etc/shadow file stored in memory we were able to get xlock to dump the contents of the file.

- heap overflows have been widely exploited in numerous major programs, including the BIND TSig bug.

So don't think you're safe if you're using strcpy's on data not on the stack ;)

Its well integrated into just about every web development system you can name.

Admittedly a good thing, but more the 'fault' of the PHP/etc developers than MySQL. PHP being a bad example as it also has excellent PostgreSQL support. Point being it was very popular and therefore everyone wants to make sure their software hooks into it well, not because MySQL put the work in.

At least you can figure out how much it costs. I can't say how much customers love hearing about ORACLES price by the system you install it on system.

Not really targetted at the same audience though is it? Say A.C.I.D to one of your clients, and watch their faces screw up in utter confusion.

Its not one of Microsofts line of swiss chese products that have more holes than a typical sieve. Slammer worm anyone ?

As we can see here, here, and here (the list goes on, as with the vast majority of software packages), it's not only MsSQL that's had it's share of vulns - it's just that no-one bothered to take advantage of the recent MySQL ones to spread a worm.

Just my 2c, but you could have picked a lot better points for your argument there :)

actually the newer worms are using 445 (SMB over TCP). And yes, my IDS devices have seen a HUGE increase of scanning activity on/for that port.... most probably due to the events mentioned in Certs CA-2003-08 found at http://www.cert.org/advisories/CA-2003-08.html

Cyber Warning Information Network (CWIN) looks to be an expensive, slower, and less effective version of CERT.

These is the group that "handled" the recent announcement of a new sendmail vulrenability. Except what they did was this: ISS, a info-security company looking for browie points reported to Office of Cyberspace Security at the White House and Homeland Security, who told FedCERT which passed that along to military and federal government IT people. Except all they could do was turn off sendmail, since a fixed wasn't yet available!

Then Sendmail (.com and .org sides, i.e. Eric Allman) and CERT was contacted. CERT alerted various Unix, Linux and BSD vendors that a new sendmail security fix was coming and to get ready to package it. Sendmail shared their fix with vendors and everyone announced a fix at roughly the same time. Thanks to the hard working people at CERT. Nobody played "I'm fixed, screw the rest of you" or other selfish self-centered games.

So the DHS made three phone calls (or emails) and spent the rest of their time writing up press releases about their great job, so the "press release == news" media could spout how great and cyber-aware DHS is. Though ISS, Sendmail Inc./ Consortium, and CERT did all the real work.

I was thinking the same thing you were at first with CERT being cut out of the picture. CERT is an independent organization.. and they rely on people telling them stuff. It seems in this case.. as far as patching and notification of the initial vulnerability.. but they weren't cut out of what they do best, which is Archiving all of the notifications and making it easy to get patch info, once it comes available. Its not like CERT actually makes they patch. As you can see HERE CERT has a notification about this one.. seems CNET left out that LinkCERT I think, at least now with this development, works much more like Slashdot.. in that they get notified of the news and they post it all on their site. Of course if its the first time anybody has heard of it they notify affecting people first, so as not to create unneeded havoc, with hackers getting to the vulnerability first.

So CERT will still go on. In this case all the people involved cut out CERT voluntarily, ISS,SANS, FedCIRC and the like. I'm sure of course CERT (in that they have a notification about it) wasn't really cut out.. then again.. they didn't neccessarily do all the coordination work.. they're proabably happy about that one. They can worry about other stuff. My opinion everybody should be this involved in fixing security issues.

With all of the vulnerabilities in BIND thank goodness the folks at VeriSign finally switched to something else!

a) no security/virus scanner,

b) using old/not up to date/no longer supported versions of software?
Now imagine those same people using the exact same piece of software that is acting as firewall and/or virus protection... Don't tell me the general public won't have this stuff installed, hell it'd be thrown in as just one more lure to the average Joe as just one more perk because viruses are such big news items lately. Ok, so let's dumb it down so the average Joe can easily update the program with patches with out having to know anything technical. Ok, to keep things simple it'll be installed in a default directory with pretty graphics, limited options and automatically connects to a government owned update server. Hrm, doesn't sound like much fun now does it? So what's the solution? Tell you what, why don't you package your open source, "on your front porch" security package, convince the government that they can make it simple enough for the general public to understand and use, that support costs will be minimal (because it is open source!) and that they should make a push for everyone to use it so that we can squash this nasty virus stuff once and for all? Get back to me on how that goes, m'kay?

Oh, and since you were so nice as to liberally quote me...

If you want to affect the WWW at large, you attack that which comprises more than half the entire WWW, that being Apache.

a) no security/virus scanner,

b) using old/not up to date/no longer supported versions of software?
Now imagine those same people using the exact same piece of software that is acting as firewall and/or virus protection... Don't tell me the general public won't have this stuff installed, hell it'd be thrown in as just one more lure to the average Joe as just one more perk because viruses are such big news items lately. Ok, so let's dumb it down so the average Joe can easily update the program with patches with out having to know anything technical. Ok, to keep things simple it'll be installed in a default directory with pretty graphics, limited options and automatically connects to a government owned update server. Hrm, doesn't sound like much fun now does it? So what's the solution? Tell you what, why don't you package your open source, "on your front porch" security package, convince the government that they can make it simple enough for the general public to understand and use, that support costs will be minimal (because it is open source!) and that they should make a push for everyone to use it so that we can squash this nasty virus stuff once and for all? Get back to me on how that goes, m'kay?

Oh, and since you were so nice as to liberally quote me...

If you want to affect the WWW at large, you attack that which comprises more than half the entire WWW, that being Apache.

a) no security/virus scanner,

b) using old/not up to date/no longer supported versions of software?
Now imagine those same people using the exact same piece of software that is acting as firewall and/or virus protection... Don't tell me the general public won't have this stuff installed, hell it'd be thrown in as just one more lure to the average Joe as just one more perk because viruses are such big news items lately. Ok, so let's dumb it down so the average Joe can easily update the program with patches with out having to know anything technical. Ok, to keep things simple it'll be installed in a default directory with pretty graphics, limited options and automatically connects to a government owned update server. Hrm, doesn't sound like much fun now does it? So what's the solution? Tell you what, why don't you package your open source, "on your front porch" security package, convince the government that they can make it simple enough for the general public to understand and use, that support costs will be minimal (because it is open source!) and that they should make a push for everyone to use it so that we can squash this nasty virus stuff once and for all? Get back to me on how that goes, m'kay?

Oh, and since you were so nice as to liberally quote me...

If you want to affect the WWW at large, you attack that which comprises more than half the entire WWW, that being Apache.

of course Linux/Unix never gets worms does it

why am i paying the goverment to fix peoples home made software ? oh yeah because it attacks them

Rebooting clears the worm from memory and don't most people shut their laptop off when they carry it in to work? Actually we quite a few laptops and desktops that needed patching and the users had no idea that they had MSDE or SQL server running. Windows Update doesn't notify these users that they need patches, and these users definitely include the types that would have no idea that they need to track down obscure patches that didn't even, until this weekend, have an install routine. MSDE installs by default with Visual Studio .NET, ASP.NET web matrix tool, Office XP Developer, MSDN subscription, Accesss 2002, Visual FoxPro 7/8 and can be redistributed by vendors. Even worse, MSDE and SQL server install with a blank password, although I think it warns on install now.

Some snippets from there:

Mabu's message says: Here's what we've been able to learn, at 4:30am Central time.

We have reason to believe that something called the "SQL Worm" is in play. Some sort of DDOS attack which creates overwhelming traffic on port 1434. This is all preliminary stuff, so take it as such but I have one link up and 3 others down.

I don't have confirmation or details on what systems are affected but we have information to indicate that the following networks are currently affected: Quest, Cable & Wireless, Broadwing, Sprint (partially). My Worldcom link seems to be unaffected (which is why I can post). Note that the connectivity interruptions may be regional but that's what we are dealing with in the South Central area of the US. This has been going on now for about 4-5 hours.

What we are seeing is a major outage due to DDOS on port 1434, on portions of the Internet backbone. At this point, the exact pattern of the outage has not been clarified.

Expect the problem to potentially be addressed when the backbone providers start filtering port 1434. However, it's taken them at least four hours to figure this out.

We just got notice (a few moments ago) that Quest finally started filtering port 1434 and everything went back up. So now we need to figure out what vulnerability this was. My information indicates that port 1434 is MS SQL server resolution service (see related CERT advisory [cert.org]. My initial impression is that while this vulnerability was discovered awhile back, someone just recently figured out a very effective exploit using the vulnerability. I am looking forward to hearing more about what people find out.

The issue currently happening, from what anyone can tell at any rate is that a flaw in MSSQL has been found, due to everyone noticing a lot of traffic on 1434.. MSSQL port anyhow, I was running MSSQL earlier and my dns crapped out ctrl+alt+del'd and saw 85% cpu used by mssql server, killed it and boom everything was okay, possibly a worm traveling around, http://internethealthreport.com/ UUnet seems absolutely destroyed ;)

I'm watching my firewall logs fill up even as I type, and all the 1434 hits are coming from different IPs... no dupes yet that I can see (maybe there are... but I'm not planning on sitting here all night reading logs).

http://www.nextgenss.com/advisories/mssql-udp.txt is an advisory about port 1434

http://average.matrix.net/Daily/markR.html shows a vivid picture of overall net health due to this

SQLServer listens to 1434 to accept incomming connections. SQLServer 7 would then normally transfer these connections to 1433 by default. SQLServer 2000 would transfer the connection to a random port.

It's best to 'hide' the SQLServer from the internet, and/or disable TCP/IP listening for SQLServer totally when it's connected to the Internet. MS also suggests SQLServer should never be exposed to the Internet directly. You can hide SQLServer (2000) directly, using the Server network utility, shipped with SQLServer. You can there first deselect TCP/IP as a protocol that's active, and if you need it, you can select 'hide' to hide the server on the internet, however it's better to disable TCP/IP totally, since you do not need it when you work with SQLServer from the same box (f.e. a website running on the same box accessing the SQLServer).

Oh, of course it should be mentioned, there is a patch for this available at MS' technet site.

http://www.kb.cert.org/vuls/id/370308 may be the CERT article related to this vuln.

Resent-From: mbac@romulus.netgraft.com
From: Michael Bacarella Date: Fri Jan 24, 2003 11:11:41 PM America/Los_Angeles
Resent-To: bugtraq@securityfocus.com
To: nylug- talk@nylug.org, wwwac@lists.wwwac.org, linux-elitists@zgp.org
Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

I'm getting massive packet loss to various points on the globe. I am seeing a lot of these in my tcpdump output on each host.
02:06:31.017088 150.140.142.17.3047 > 24.193.37.212.ms-sql-m: udp 376
02:06:31.017244 24.193.37.212 > 150.140.142.17: icmp: 24.193.37.212 udp port ms-sql-m unreachable [tos 0xc0

It looks like there's a worm affecting MS SQL Server which is pingflooding addresses at some random sequence. All admins with access to routers should block port 1434 (ms-sql-m)!

Everyone running MS SQL Server shut it the hell down or make sure it can't access the internet proper! I make no guarantees that this information is correct, test it out for yourself!

-- Michael Bacarella 24/7
phone: 646 641-8662
Netgraft Corporation http://netgraft.com/
"unique technologies to empower your business"
Finger email address for public key. Key fingerprint: C40C CB1E D2F6 7628 6308 F554 7A68 A5CF 0BD8 C055

Here's what we've been able to learn, at 4:30am Central time.

We have reason to believe that something called the "SQL Worm" is in play. Some sort of DDOS attack which creates overwhelming traffic on port 1434. This is all preliminary stuff, so take it as such but I have one link up and 3 others down.

I don't have confirmation or details on what systems are affected but we have information to indicate that the following networks are currently affected: Quest, Cable & Wireless, Broadwing, Sprint (partially). My Worldcom link seems to be unaffected (which is why I can post). Note that the connectivity interruptions may be regional but that's what we are dealing with in the South Central area of the US. This has been going on now for about 4-5 hours.

What we are seeing is a major outage due to DDOS on port 1434, on portions of the Internet backbone. At this point, the exact pattern of the outage has not been clarified.

Expect the problem to potentially be addressed when the backbone providers start filtering port 1434. However, it's taken them at least four hours to figure this out.

We just got notice (a few moments ago) that Quest finally started filtering port 1434 and everything went back up. So now we need to figure out what vulnerability this was. My information indicates that port 1434 is MS SQL server resolution service (see related CERT advisory. My initial impression is that while this vulnerability was discovered awhile back, someone just recently figured out a very effective exploit using the vulnerability. I am looking forward to hearing more about what people find out.

There is a patch available for this and it has been available for 6 months. So if your server is infected it is because you weren't paying attention/lazy/whatever. Go Here for the patch, or Here to read the CERT bulletin.

Oops, 2nd link should be to CERT.

This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.

There are not enough daemons written in other languages to determine if security exploits would be present in them. No one thought bind and sendmail were so insecure when they implemented them. A careful look would have revealed that, just because Java so far doesn't look insecure doesn't mean it is.

But you are wrong about SSH, go to CERT and search for SSH. The first 5 (that's all I checked) were implementation problems _NOT_ buffer overflow problems.

C behaving as it is designed is no consolation if the design is bad

The design isn't bad. At the time it was developed (1970s) it was revolutionary with what it could do. Programmers had a better sense of constraint (working in smaller memory spaces) as well as more discipline. I'm curious, but do you actually know C? I mean really know it. Know the caveats of realloc? If so, I'd find it odd that you think C is bad by design.

is not necessarily a more secure web site. You do get less customers calling up because the SSL warning box popped up. i.e.
You are buying off the need to provide more customer support when you pay for an SSL certificate which has a root signing cert already present in the popular browsers.
You are not buying authenticity of sites. We all remember Verisign being tricked into issuing Microsoft certificates to a poseur, right?

Not mentioned anywhere by anyone so far: should we trust Macromedia's plug-in? One reason I don't allow the Flash plug-in to be installed on my computer is that I don't understand everything that it does, and how an author can mis-use the language to do things they shouldn't. Paranoid? Of course.

So I did a search here on the CERT site to see the kinds of headaches that have been reported with Flash. The returned response shows that the plug-in isn't too awful, but still it is bad enough to tilt the scales in my case to not supporting Flash at all, on any platform. YMMV

The same search of the CERT size for "svg" didn't yield anything, but that just means no one has found the hole yet, if there is one. Separating SVG and the multimedia functions means less opportunity for screwing up, or at least confining the exposure of any screwup. Maybe.

Besides, I have yet to find any good use of Flash as a customer -- but then again, I'm a proponent that Web pages should inform, not entertain or mesmorize. Corporate America won't like my attitude, I'm sure.

Cert announcement.

The Computer Emergency Response Team (CERT) Coordination Center has warned of a serious security vulnerability in the Internet Software Consortium's (ISC) DHCP (Dynamic Host Configuration Protocol) software, which is shipped with multiple operating systems including popular Linux and BSD variants.

Cert announcement.

The Computer Emergency Response Team (CERT) Coordination Center has warned of a serious security vulnerability in the Internet Software Consortium's (ISC) DHCP (Dynamic Host Configuration Protocol) software, which is shipped with multiple operating systems including popular Linux and BSD variants.

Then, the skr1pt k1dd1es show up and start a 'trinoo' or 'tribal flood' type DoS that floods your network and slows all your servers down to a crawl.
Crap !!
You get most of the solutions out here

And for trinoo and TFN go here

Then, the skr1pt k1dd1es show up and start a 'trinoo' or 'tribal flood' type DoS that floods your network and slows all your servers down to a crawl.
Crap !!
You get most of the solutions out here

And for trinoo and TFN go here

My reading: Microsoft doesn't make any vulnerable drivers (Microsoft doesn't make (m)any Ethernet drivers). Their sample code is vulnerable, and in the future they will be testing drivers for this bug before certifying them. -- Current MS certified drivers May be vulnerable -- especially if they used MS's suggested code snippet.

In short, YMMV.

Eweek has their typical (puffy, low on tech details) take on it here. Since they don't specify the OS, I'm assuming these are drivers for Windows.

"The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."

Secondly, This is a Hyperlink. They are sometimes used on the World Wide Web, to link relevant and useful resources together. Had you followed this particular link, you would have found the CERT advisory about the problem AND a link the @Stake's own advisory and white paper about the problem.

Thank you

From CERT Advisory:
[...]
MandrakeSoft Unknown 3-Jan-2003
Microsoft Corporation Not Vulnerable 3-Jan-2003
MontaVista Software Unknown 3-Jan-2003
NEC Corporation Not Vulnerable 3-Jan-2003
NetBSD Unknown 3-Jan-2003
NetScreen Unknown 3-Jan-2003
Network Appliance Vulnerable 8-Jan-2003
Nokia Unknown 3-Jan-2003
Nortel Networks Unknown 3-Jan-2003
OpenBSD Unknown 3-Jan-2003
Openwall GNU/*/Linux Unknown 3-Jan-2003
Red Hat Inc. Unknown 3-Jan-2003
[...]

Hmm... Too bad the facts are in your way. Of course, I understand that FUDers don't bother looking at facts.

Drivers for linux are vulnerable so do need fixing. (p.s., sorry for the bad link in the original post, I meant: CERT note)

If you read the actual CERT Vulnerability note and seen that Windows is not vulnerable.

Wow, according to this Windows is NOT vulnerable

According to another post here Linux IS vulnerable

Reading the fluff piece isn't good enough. Go to the source and get the real deal.

This doesn't look like the serious flaw it was posted as.

Cisco's Status/Statement
and
Full CERT Advisory

Cisco's Status/Statement
and
Full CERT Advisory

Microsoft Corporation Not Vulnerable 3-Jan-2003

The pad of older data in a 46 byte header can't contain a lot of data.

In addition, you also have to be able to get this data. As mentioned by mmol_6453, you can only get the Ethernet frames if you are on the same LAN or if the victim is tunneling the Ethernet frames through a VPN. If there is an IP router between you and the victim, you will probably not be able to get the leaked bytes (and I am glad to see that several routers listed in the CERT advisory are not vulnerable).

The advisory says: "the leaked information may originate from dynamic kernel memory, from static system memory allocated to the device driver, or from a hardware buffer located on the network interface card.". If you are using a broadcast Ethernet medium, then the leaked information collected from the static memory of the device driver or from the hardware buffer on the NIC will probably be much less than what could be collected by running a packet sniffer on the same Ethernet segment, because the leaked bytes will come from previous packets. However, this is different if you are running a switched Ethernet network (not broadcast) because the packet sniffers are less useful in this case.

As I see it, the only real potential for information leakage comes from the device drivers that are leaking bytes from the dynamically allocated kernel memory. Then you could get almost anything from that machine, not only something that is supposed to be sent over the network. On the other hand, it is probably very hard to predict what will be leaked.

It would be interesting if the advisory could give a list of operating systems that are leaking random information from the kernel versus those that are leaking information from the previous packets (in the driver or in the NIC). I would be more worried about the former than the latter.

Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

You mean Microsoft said they aren't vulnerable. But look at these weasel words: "However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue." Draw your own conclusions.

Microsoft Corporation Not Vulnerable 3-Jan-2003

You can find the CERT's take on this here:
http://www.kb.cert.org/vuls/id/412115.

In addition (I post too fast), the CERT has made available a list of vulnerable systems that they know of.
Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

Yet according to the Cert list referenced in the article, MS Windows systems are not affected, and most Linux distros are listed as "unknown".