Slashdot Mirror

Once again, for the benefit of the retarded. Linux is a kernel. Userspace programs run on the kernel. Userspace programs are written in programming languages, then compiled for an architecture, and operating system.

Are you saying the current ATM software doesn't need to be "customized" for Windows XP/Embedded? Or just that it would be more difficult to "customize" for Linux than Windows? I would think an application running the QT for framebuffer that was talked about recently would be significantly less complex, and would require fewer "experts to keep them running". If not there are others available

Keep in mind Linux is available for $0.00 per processor, which is (my math is a little shaky this morning) 100% cheaper.

Microsoft are not stupid if they are making a windows version for ATMs they will *Make sure* it is 100% secure.

This has to be a troll, but I'll bite. Microsoft is more concerned about ATM's than nuclear powerplants?

Even the suspected author of one variant of the MS Blaster worm, Jeffrey Parson, was told by the judge that he could use the Internet to look for work. Judges are increasingly unwilling to place permanent draconian restrictions on computer criminals because that could leave them unemployable, and an unemployable person can be forced back into crime by that very fact.

After a weekend in hiding, Lamo turned himself in at the federal courthouse in Sacramento, Calif., Tuesday morning. Pursuant to an agreement with prosecutors, he was quickly released on a $250,000 bond secured in part by his parent's house, but was banned from computers, ordered to obtain employment and placed on travel restrictions pending trial

Researchers from iDefense Inc. of Reston, Va., who found the new attack software being distributed from a Chinese Web site, said it was already being used to break into vulnerable computers and implant eavesdropping programs. They said they expect widespread attacks similar to the Blaster infection within days.

Sendmail 8.12.9 prescan bug

attack details:

Local exploitation on little endian Linux is confirmed to be trivial
via recipient.c and sendtolist(), with a pointer overwrite leading to a
neat case of free() on user-supplied data, i.e.:

eip = 0x40178ae2
edx = 0x41414141
esi = 0x61616161

SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242

0x40178ae2 : mov %esi,0xc(%edx)
0x40178ae5 : mov %edx,0x8(%esi)

Remote attack is believed to be possible.
It also seems that a CS student from the university of Sweden has posted a working exploit on this web site. Scary stuff. So patch your system, people!

But it is common for irresponsible vendors *cough*redhat*cough*debian*cough to fsck everyone else when they are invited to this groups.

Remember some vendors have multiple versions to update, and a lot of testing before releasing. At least a whole day of work.

Sure, full disclosure ppl would argue that, but maybe there's a middle chance... for example telling ppl some workarounds (if there are) just after knowing the patch, but way before releasing the advisories/patches.

Anyway, I hate here on /. ppl claim stuff like crazy. And instead of blaming the vendor arseholes who shoot others in the back for nothing, blame responsible and respected agents (be it a vendor or someone like Theo)

http://www.securityfocus.com/archive/1/337662/2003 -09-13/2003-09-19/0

The systems are designed to run without monitoring. However, without human intervention, the systems aren't very good at staying up in exceptional circumstances. My guess is a computer failure made the grid much more vulnerable, to the extent where something routine brought it down.

Something else to add: a while ago in Ohio, a nucler power plant had its control systems down for a while as a result of msblaster.exe. Thankfully, the plant was off anyway, but it shows that sysadmins are just as bad in power infrastructure as they are in the rest of the commercial sector.

If there's a sufficiently large hole in a sufficiently distributed product (sendmail, bind, apache, etc.)

There is - iDEFENSE Security Advisory 09.10.03: Two Exploitable Overflows in PINE

hackers could launch attacks against unprotected systems as early as day's end. "It's going to be trivial," he said. "This is an instant replay of a few weeks ago."

hackers could launch attacks against unprotected systems as early as day's end. "It's going to be trivial," he said. "This is an instant replay of a few weeks ago."

I know a lot of people look at it and say, "Oh, but he had good intentions, that makes it ok!" It's not really like that...we don't KNOW his real intentions at all, just what he SAYS his intentions are.

While I agree with the content of your post, I would wager that this would be treated like any other criminal charges. By reviewing his public track record at Security Focus most people investigating Mr. Lamo's public past would deduce that he probably wasn't doing anything vindictive or with ill intent. For example, as quoted from the previous link:

WorldCom is the latest target of a clean-cut 20-year-old hacker who's already drawn national attention discovering, exploiting, and then warning about serious security lapses at AOL, Excite@Home, Yahoo! and Microsoft. Like those other companies, security staff at the $20 billion communications giant might be surprised to learn they were compromised by a lone vagabond hacker who lives out of a weathered L.L. Bean backpack and does most of his work from Kinko's 'laptop stations,' using little more than a Web browser and his wits.

While it doesn't make his activities any less illegal, it lends evidence that he had no motive other than exposing a security flaw with the NYT. Provided that's what Mr. Lamo is actually being charged with.

Personally, I think people like Mr. Lamo make the world a better place. Sometimes, you don't know about an insecurity ( or don't care ) until someone actually does something to your information. Much like how I was raised to always lock doors and windows, but a lot of my friends don't seem to see the point. When their belongings go missing, I won't even bother saying, "I told you..."

Linksys has an email address, security@linksys.com set up so that you can report things like this. Tech support is for people who can't tell the LAN cable from the WAN cable, or need to be told to power-cycle their routers.

And if you don't hear anything back for a while after emailing them there, try posting it to Bugtraq -- that'll get their attention, if nothing else.

This story would tend to indicate the opposite (i.e. that it may well be possible). While the disabled system in question (the monitoring system of the Davis-Besse nuke plant) was not directly related to control, it's fair to say that a worm that crashes process monitoring systems is a serious security problem. How are you supposed to control a system that you can't monitor? (sure, you can run to manual or analog backups, but that takes time, causes operator confusion, and is just not a great solution to the fundamental problem.)

In addition, a recent Wired story ( here) talks about how in the minutes before the power outage, engineers were having computer problems. At the very least it appears that these computer issues were preventing or slowing down operator responses to the developing problem.

As stated above our protection and control systems send data via leased phone lines and/or private fiber and do not have any connection to the Internet. Thus no possible way of receiving a virus.

As stated in the story about Davis-Besse, the work came in through a T1 line put in place by a contractor (between the plant and the home office), neatly circumventing the firewall. In other words, there was a connection to the internet. How could this be allowed to happen? Are these people stupid, lazy, or just incompetent? it also shows that you may think there is no internet connection, but you can't always be sure (unless you use a totally different protocol).

By the way, a leased phone line presumably goes through a phone switch; these tend to be computer controlled and sometimes open to compromise. A determined intruder could use this to hijack the leased line and inject spurious control commands.

And regarding viruses, a direct internet connection is not the only possible route of infection. A virus could also ride in on a disk (intentionally or unintentionally), or be injected in a microwave link (that's what we did to Serbian air defence networks a while back).

Part of my job is to study disturbances on the grid (ie why did the lights go out?). The studies take anywhere from a day to months to explain what happened. And remember the 1965 blackout study took over a year to finish.

The problem is that First Energy is publicly dissembling ("It's sooo complicated. Zillions of things going on all over the place. It can't all be our fault."), and this does not inspire confidence in them, or in the process of figuring out what happened. Basically, the public is going to get to watch as our power infrastructure is sold to a few private interests, while things like reliability go down the toilet. And we'll be mushroomed (kept in the dark and fed bullshit) when things go wrong. We were lucky that it was just a blackout, rather than, say, a nuke plant meltdown. (That would among other things finally kill nuke power, which would be a damned shame).

So you are denying the claims laid in this article and this notice from the US Nuclear Regulatory Commission?

Even the NRC admits that a contractor established an unprotected computer connection to its corporate network, through which the worm reached the plant network.

Seems like the philosophy got kicked out the door for some reason.

There were Multiple Linux Kernel 2.4 Vulnerabilities recently reported. Yet I didn't notice a front page article from Slashdot concerning that.

Here's an idea, editors: try to at least to pretend to be unbiased. I'm sure you still can get your ad-revenue boosting comment circlejerks even with a bit of balanced reporting thrown in.

The system is ultimately ineffective (screen shots anyone?, hand made copies?, pocket cell-phone cameras?), and false security is worse than none

It requires additional infrastructure (cost) and software upgrades (cost) then locks you in to the M$ implementation

Companies (financial) will have to manage (cost) the new documents to meet compliance issues (ie: you can NOT have documents that are required to be kept for compliance be protected from copying or have them expire - and how do you stop it?)

Single point of failure:What if the DRM server is down (temporary downtime company-wide for M$ Office)

What if the DRM server crashes and can't be restored (permanent loss of important data)

Will M$ provide a backdoor (for Law Enforcement, PATRIOT ACT, etc), what if it's leaked ?

THIS IS A DOCUMENT MANAGEMENT ISSUE - not a security problem, people need EDM/ECM not more gimmicks !

'Hacking' into the document to provide interoperability or to recover data may be a FEDERAL OFFENSE under DMCA

What about search/rescue for the users who screw up and lock themselves or others out of documents accidentally ???

Forced upgrades (al la Win2K) just to continue to use YOUR OWN (DRMed) corporate assets

Louts Notes has had a (less user-friendly) version of this since R2, and very few shops use it (encryption keys)

On the bright side:

There are a huge number of users/customers/vendors/partners who will not be able to use the DRM documents (requires upgrade), so it will take years to even marginally implement for external communications (which is one of the main items people want it for in the first place)

Some obvious possibilities for abuse include:

Stopping Whistleblowers (Enron, Pentagon, Worldcom/Arthur Anderson, Whitewater)

Erasing potential evidence: stockbroker send you bad advice in a doc that expires in 30 days

Erasing potential evidence: boss tells you to do something unusual that gets you into trouble

Erasing potential evidence: employees colluding to do things detrimental to a company (embezzle?)

Mafia can us it for betting slips, other low-level secure comms

Word/Excel macro viruses could be set to self-destruct to protect the guilty

Restricting fair-use rights

The Terrorists could use it !

See Also:
http://www.securityfocus.com/columnists/165

People should just use some of the great security sites out there. E.g. SecurityFocus or Secunia. Both have a large vulnerability database and mailing list with all the latest vulnerability information.

http://www.securityfocus.com

Note: Flaws like "Race condition allows local user to DoS emacs" are akin to notepad running unusually slowly. Which is to say, not critical. But they fully disclose and fix them anyway becuase they don't have a stock value to keep inflated.

* security through obscurity will only stave off the inevitable. see Heterogeneity as a form of obscurity, and its usefulness (scroll down to the middle of the page, the threading got messed up somehow).

* stick with commodity hardware, which by virtue of being common, are "integrated and well known".

* stick with commodity hardware in beige boxes and prices are absurdly low. maybe you won't get the logo on the box, but there are many small businesses that can make competitive alternatives to the products and services you get from ibm or dell (or hp or sun or valinux) -- especially in a low volume situation (one machine? psha whateva!)

i'm glad you think $3k for a laptop is a "not so bad" deal. i'm sure it's very nice hardware, but like porsches and bmw's and mercedes, how much of that is the logo?

Subject: schvalne jestli ve SCO ctou ceske servery
From: root
Date: Fri, 29 Aug 2003 05:59:24 -0600
To: redakce@root.cz

That seems to be Friday morning, just before 6:00am by my reading.

I also wonder if their mail server may still be vulnerable to this little problem

Security Focus is offline!

http://www.cnn.com/2003/US/08/16/blackout.chron.ap /index.html

One thing is clear : the timely coincidence between MSBLAST and power blackout is certainly _there_. The following postings on securityfocus.com shows that the SCADA systems run on Windows 2000/XP and some are connected to the internet.

http://www.securityfocus.com/archive/1/333505/2003 -08-13/2003-08-19/0

" I believe that the outage was caused by the MSblaster, or its mutation, which was besieged upon the respective vulnerability in certain control and monitoring systems (SCADA and otherwise) running MS 2000 or XP, located different points along the Grid. Some of these systems are accessible via the Internet, while others are accessible by POTS dialup, or private Frame relay and dedicated connectivity. "

http://www.securityfocus.com/archive/1/333513/2003 -08-13/2003-08-19/0

SCADA manuals : http://www.automationtechies.com/sitepages/pid641. php

The following is very interesting : http://www.pbs.org/wgbh/pages/frontline/shows/cybe rwar/view/
its a Documentary about cyberwar and its impact on America after 911, and brought online on apr. 24, 2003. Inside video #4 and #6 Gen. Clark from the Pentagon and other government security officials clearly state that Cyberwar Criminals (El-Queida members are named as possible candiates) can takedown large parts of the American Powergrid.

So when Mr. McSlarrow talks about things like: "we must extensively investigate the cause of power fallout here, and new power bill de-regulations must be introduced", i can only think of yet another mass media attempt to distract the attention in other directions. Why does No-One mention the failing of Microsoft's software? Why does No-One mention that the Government should disallow using Microsoft software for essential services, like power-grid, healthcare, airport flight navigation etc.?

Robert

http://www.cnn.com/2003/US/08/16/blackout.chron.ap /index.html

One thing is clear : the timely coincidence between MSBLAST and power blackout is certainly _there_. The following postings on securityfocus.com shows that the SCADA systems run on Windows 2000/XP and some are connected to the internet.

http://www.securityfocus.com/archive/1/333505/2003 -08-13/2003-08-19/0

" I believe that the outage was caused by the MSblaster, or its mutation, which was besieged upon the respective vulnerability in certain control and monitoring systems (SCADA and otherwise) running MS 2000 or XP, located different points along the Grid. Some of these systems are accessible via the Internet, while others are accessible by POTS dialup, or private Frame relay and dedicated connectivity. "

http://www.securityfocus.com/archive/1/333513/2003 -08-13/2003-08-19/0

SCADA manuals : http://www.automationtechies.com/sitepages/pid641. php

The following is very interesting : http://www.pbs.org/wgbh/pages/frontline/shows/cybe rwar/view/
its a Documentary about cyberwar and its impact on America after 911, and brought online on apr. 24, 2003. Inside video #4 and #6 Gen. Clark from the Pentagon and other government security officials clearly state that Cyberwar Criminals (El-Queida members are named as possible candiates) can takedown large parts of the American Powergrid.

So when Mr. McSlarrow talks about things like: "we must extensively investigate the cause of power fallout here, and new power bill de-regulations must be introduced", i can only think of yet another mass media attempt to distract the attention in other directions. Why does No-One mention the failing of Microsoft's software? Why does No-One mention that the Government should disallow using Microsoft software for essential services, like power-grid, healthcare, airport flight navigation etc.?

Robert

Java Anonymous Proxy was backdoored by Court order. Here is a link.

Here is some more information on the vulnerability actually used to crash the train signalling network in Maryland.

here. Surprised this hasn't shown up on Slashdot yet.

"The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours, despite a belief by plant personnel that the network was protected by a firewall, SecurityFocus has learned."

...

"The Davis-Besse incident was not Slammer's only point of impact on the electric industry. According to a document released by the North American Electric Reliability Council in June, Slammer downed one utility's critical SCADA network after moving from a corporate network, through a remote computer to a VPN connection to the control center LAN.

"A SCADA (Supervisory Control and Data Acquisition) system consists of central host that monitors and controls smaller Remote Terminal Units (RTUs) sprinkled throughout a plant, or in the field at key points in an electrical distribution network. The RTUs, in turn, directly monitor and controls various pieces of equipment.

"In a second case reported in the same document, a power company's SCADA traffic was blocked because it relied on bandwidth leased from a telecommunications company that fell prey to the worm.

"Reports on the effect of last week's Blaster worm on the electric grid, if any, have yet to emerge."

Interesting story. CNN and a bunch of people on NANOG (www.nanog.org) were speculating that this outage was caused by the msblaster worm. This story backs up at least the feasibility of that.

http://www.cnn.com/2003/US/08/16/blackout.chron.ap /index.html
The timely coincidence between MSBLAST and power blackout is certainly _there_.

http://www.securityfocus.com/archive/1/333505/2003 -08-13/2003-08-19/0
http://www.securityfocus.com/archive/1/333513/2003 -08-13/2003-08-19/0
http://www.automationtechies.com/sitepages/pid641. php

http://www.pbs.org/wgbh/pages/frontline/shows/cybe rwar/view/
aspecially watch video #4. Just after 911 a cyber terroristic attack againts the powergrid was warned for by Gen. Clark from the Pentagon and other cyber security officials.

Robert

http://www.cnn.com/2003/US/08/16/blackout.chron.ap /index.html
The timely coincidence between MSBLAST and power blackout is certainly _there_.

http://www.securityfocus.com/archive/1/333505/2003 -08-13/2003-08-19/0
http://www.securityfocus.com/archive/1/333513/2003 -08-13/2003-08-19/0
http://www.automationtechies.com/sitepages/pid641. php

http://www.pbs.org/wgbh/pages/frontline/shows/cybe rwar/view/
aspecially watch video #4. Just after 911 a cyber terroristic attack againts the powergrid was warned for by Gen. Clark from the Pentagon and other cyber security officials.

Robert

• a post
• another post
• Info on SCADA

Got me if it's true. I'm not up on that stuff. Made for some interesting reading though! :)

• a post
• another post
• Info on SCADA

Got me if it's true. I'm not up on that stuff. Made for some interesting reading though! :)

Maybe these links may enlighten the situation:
http://www.securityfocus.com/archive/1/333505
and
http://www.gregpalast.com/detail.cfm?artid=257&row =0

How about this

Or this

I've had patches fail to install, or not even get listed thinking they were already installed, as well as cases where something is already installed and it believes an installation is necessary.

Just try reinstalling a system and restoring a backup of it, using the built-in xp backup tools on top of it and check out the mess you get afterwards.

FUD generated by propaganda isn't even necessary, the poor state of how the whole system functions speaks for itself.

The very fact that we deal with these worms once every 2-4 months speaks for itself. If the system worked, and properly explained the danger of leaving the system unpatched we wouldn't have ISPs and government agencies complaining of down time due to a worm.

On top of that there's at least one patch each month that plugs up some kind of exploit that allows remote attackers to run arbitrary code on your system. Go ahead, reinstall your XP system from scratch and read through the descriptions for the patches. A sizable number of them patch against these sorts of issues.

On all fronts it is unacceptable.

Maybe they are dropping it because users wont accept advertising in their email client (OE did for 1 version but was quickly dropped perhaps people complained?) but if its on the web (in a browser) they can advertise all they like (look at the mess that what they call hotmail now)
then they can get advertisers to focus on associating users email accounts with user names and all that lovely personal information (courtesy of your "msn wallet(TM)" and "msn passport(TM)", tie that to your machines GUID and msn's cookie stealing exploits (notice hotmail.com does not exist anymore and is now a msn subdomain) and voila , you have WindowsXP 2004 marketing machine where you are not the customer any longer, you are the product and you will even hand over 299$ (cost of XP) for the privilege while assigning all your IP rights to them and their "partners".

Microsoft isnt a software company, its a marketing company that creates software.

not that it will affect me or you but you have to feel sorry for the sheep that have no idea whats going on.

cheers

If a system has been compromised, then you can't afford not to take it down.

Errr... not immediately, no.

Say you've just discovered that a box is compromised (e.g. you noticed an internal box portscanning your local network), you'd immediately take it down?? The whole point of forensics is to gather as much evidence as possible from the compromised machine, and shutting the box down or disconnecting it from the network means losing vital information, so you better be sure you've got as much evidence as possible before powering off. While there is always a fine balance in deciding whether or not to switch off (e.g. do I leave this box up an extra few minutes while I gather more evidence, after having discovered that the box is running a ton of SQL queries against the DB server), it should be carefully considered rather than a knee-jerk "pull the plug" approach.

Besides, the original parent poster seemed to have missed the point that the forensic analysis shouldn't be done from the compromised box; run netcat or cryptcat (from read-only media such as a CD) on it and pipe the shell to the secure forensics box (running LASL 0.4a for instance), then gather your evidence here. Depending on the compromised OS you'll need a variety of binaries on the CD to put in the suspect box, for instance the excellent PS tools are a must for Windows auditing.

For those interested in forensics it might be worth reading a paper linked off the front of SecurityFocus at the moment: Maintaining System Integrity During Forensics. While it's not really intended as an introduction it does cover the main points pretty well, so would be worth a read if you're curious.

Read more on SecurityFocus' mailing list.

I dont get it. Is this Slashdot, or is this Bugtraq??

Besides, if we start writing about OS vulnerabilities here, it will fill the ./ with mostly windows-related stuff (specially on mondays) and we *ix-geeks dont want that, do we?

The summary is misleading. The attacker was not an acxiom employee. He had legitimate business using the acxiom server to access one account (that of his employer). He used this access to get the passwords of other clients. If that doesn't count as being hacked, I don't know what does.

See the SecurityFocus article.

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

Those were all dead links.
s/yro.slashdot.org/www.securityfocus.com

1.Linux Kernel 2.4 XDR handler routines for NFSv3 have been reported prone to a remote denial of service vulnerability.
The issue presents itself in the XDR handler routine contained in the nfs3xdr.c kernel source file. The issue is due to a signed/unsigned mismatch, when processing the size field of an XDR packet.

A remote attacker may exploit this issue to trigger a kernel panic and deny service to legitimate users of the system.

2. A potential information disclosure vulnerability has been reported for the Linux /proc filesystem, specifically when invoking setuid applications. As a result, an unprivileged user may be able to read the contents of a setuid application's environment data. This could potentially, although unlikely, result in the disclosure of sensitive information, such as restricted file path information.

3.The Linux Kernel MXCSR handler code has been reported prone to an unspecified vulnerability. The issue presents itself when low-level MXCSR kernel code encounters a malformed address. It has been reported that the MXCSR code fails to sufficiently handle malformed address data and will leave garbage in the CPU state registers. Although speculative, it has been conjectured that this issue may allow an attacker to trigger a denial of service condition. Although unconfirmed other attacks may also be possible.

4.A vulnerability has been reported in the TTY layer that may result in a kernel panic. The precise technical details of this vulnerability are currently unknown. This BID will be updated as further information is available.

5. It has been reported that the Linux kernel does not properly handle a low volume flood of some types of traffic. Because of this, an attacker may be able to cause excessive consumption of resources and failure to route traffic.

6. It has been reported that the Linux kernel does not properly handle some specific types of network traffic. Because of this, an attacker may be able to cause excessive consumption of resources with malicious TCP/IP packets, resulting in a denial of service.

7. A vulnerability has been discovered in the ioperm system call for Linux. Due to a programming error, permissions may not be correctly configured on I/O ports used by a process. As a result, an unprivileged local user may be capable of reading and writing to I/O port addresses which they would not normally have access to.

8. A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges. The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes. This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

9. Network device drivers for several vendors have been reported to disclose potentially sensitive information to attackers. Frames that are smaller than the minimum frame size should have the unused portion of the frame buffer padded with null (or other) bytes. Some device drivers do not do this adequately, leaving the data that was stored in the memory comprising the buffer prior to its use intact. Consequently, this data may be transmitted within frames across ethernet segments. As the ethernet frame buffer is allocated in kernel memory space, sensitive data may be leaked. Cisco has state

• ncacn_ip_tcp : TCP port 135
• ncadg_ip_udp : UDP port 135
• ncacn_np : \pipe\epmapper, normally accessible via SMB null session on TCP ports 139 and 445
• ncacn_http : if active, listening on TCP port 593.
• 
  ... and finally, even port 80 might be used if ncacn_http is active, and COM Internet Services is
  installed and enabled.
  

Check out CERT, a good site for this stuff. Here's their warning (more info than DHS). A list of what they have to block:
135/TCP
135/UDP
139/TCP
139/UDP
445/TC P
445/UDP

Also, it appears 4444 is being used,

Security Focus's incidentmailing list is also enlightening. And for good measure, a posting on the ineffectiveness one of MS's patch (as of 29 Jul).