Slashdot Mirror

I assume this is an internet explorer based exploit? http://www.kb.cert.org/vuls/id/776931

"ActiveX" itself is not necessarily the problem. ActiveX is a commonly used format for packaging native code in a way that it can be used by Internet Explorer. If that code contains a flaw, then Internet Explorer can be used as an attack vector for that buggy code. For example, if that code is written in C and it doesn't properly handle strings, it may be vulnerable to a buffer overflow that can reached by viewing a web page. That holds true whether that code is packaged as an ActiveX control or a Netscape-style plugin.

Plug-ins (including ActiveX) are dangerous. ActiveX is much more ubiquitous than Netscape-style plugins. For example, nearly every windows application comes with ActiveX or COM objects, but it's very rare for them to install Netscape-style plugins. Therefore, using Internet Explorer with ActiveX enabled for all sites on the internet (the default configuration) is dangerous because you're relying on all of these components to be written securely.

Secure your web browser and you'll be much better off.

No one I know, nor me, use openDNS, right now, BUT, I am looking into pointing to it for my systems, and my clients. It looks VERY interesting.

Ahhahah! How up to date are openDNS machines? I would guess sate of the art, but let me poke around their DNS server...Well, the pokeing indicates that security is at the higest levels, ( of course ), and I have opened a discussion with them regarding their maintenence.

BIND is currently at 9.4.2, and 8.2.x was the one vunerable, and IIs

Hehe! Look at this:

http://vdb.dragonsoft.com/detail.php?id=3028

"ISC BIND 9 - 9.5.0a are exist remote cache poisoning vulnerability, caused by the DNS query ID generation code."

This site:

http://www.kb.cert.org/vuls/id/927905

Lists Microsoft Windows as 'Not Vunerable"

"Thank you for the heads up. While we do use the BIND protocol, we have our own implementation so these implementation-specific vulnerabilities should not affect us."

But of course, this proves that the above is a mistatement...

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3898

"The DNS server in Microsoft Windows 2000 Server SP4, and Server 2003 SP1 and SP2, uses predictable transaction IDs when querying other DNS servers, which allows remote attackers to spoof DNS replies, poison the DNS cache, and facilitate further attack vectors."

The Patch for servers is:

http://www.microsoft.com/technet/security/bulletin/ms07-062.mspx
( Nice of them to patch a vunerability that they claim they dont have! )

Ahh! The cache on YOUR dns gets poisoned.

Crist! There's a wikipage out it... ( I digress )

The security rundown on how it happens:

http://www.secureworks.com/research/articles/dns-cache-poisoning/

Step 1 - Attacker sends a large number of quires to the vicum nameserver, all for the sam domain name.
Step 2 - Attacker sedns spoofed replies giving fake answers for the quieris it made.
Get the picture?

Solution: Apply patches to your DNS server. ( i.e. patch your MS Server )

Cert notification:
http://www.kb.cert.org/vuls/id/484649

... secure your web browser. Many browsers are not secure out of the box, which puts you at risk of attack.

BAD_COMPARE
CTOR_DTOR_LEAK ; lameness
DEADCODE
DELETE_ARRAY
FORWARD_NULL
NEGATIVE_RETURNS , lameness
NULL_RETURNS
OVERRUN_STATIC
RESOURCE_LEAK / lameness
REVERSE_INULL
UNINIT
USE_AFTER_FREE

and this doesn't give me confidence in the SM team

Then you should probably stay away from Debian, Sendmail, Apache, or...well, hell, just stay away from Open Source, period, if a server/distro compromise is the measuring stick you use to measure "confidence."

This isn't a Second Life problem. It affects all QuickTime players. QuickTime has a recently discovered vulnerability which allows it to be used as a way to inject executable content into the user's machine. This can attack far more than Second Life.

See US CERT Vulnerability Note VU#659761 -- Apple QuickTime RTSP Content-Type header stack buffer overflow. "Apple QuickTime contains a stack buffer overflow vulnerability that may allow a remote, unauthenticated attacker to execute arbitrary code or cause a denial of service condition. ... We are currently unaware of a practical solution to this problem.. ... "Note that QuickTime is a component of Apple iTunes, therefore iTunes installations are also affected by this vulnerability. We are aware of publicly available exploit code for this vulnerability. Testing indicates that QuickTime versions 4.0 through 7.3 are vulnerable on all supported Mac and Windows platforms."

CERT suggests disabling all the ways QuickTime can be launched:

• Block the rtsp:// protocol
• Disable the QuickTime ActiveX controls in Internet Explorer
• Disable the QuickTime plug-in for Mozilla-based browsers
• Disable file association for QuickTime files

This vulnerability was first published on November 23, 2007.

The CERT Vuln. Note gives somewhat better information and workarounds than I have seen elsewhere. (Some places say, "just block port 554 and you're safe." Nope.)

I would like to note that while the exploit released doesn't work on IE, Symantec notes that, with work, a new exploit could target IE. (And likely other browsers. As people have noted elsewhere - this isn't really a browser issue.)

Some interesting facts.

http://taosecurity.blogspot.com/2007/11/examining-mpaa-university-toolkit.html

They are using an old version of snort that has vulnerabilities. I didn't realize the version of snort they are running is from over two years ago!

I sure hope this version they are running isn't vulnerable to this. http://www.kb.cert.org/vuls/id/175500 If so, someone could totally own the box and sniff whatever traffic they want to. All of it including the content.

• Affected OS: Windows
• Affected Browser(s): IE 7 + Firefox (together)
• Cert advisory: https://www.kb.cert.org/vuls/id/403150
• Secwatch advisory: http://secwatch.org/advisories/1018594/

Internet Explorer 7 has changed how Microsoft Windows parses URIs. This has introduced a flaw that can cause Windows to incorrectly determine the appropriate handler for the protocol specified in a URI. This flaw appears to rely on having a "%" character in the URI.

Publicly available exploit code uses Mozilla Firefox as an attack vector for this vulnerability. For more information, including workarounds, please see VU#783400

It seems that the injection mechanism is to use Firefox, but the exploit requires IE 7 to be installed on the victim's computer.

Interesting excerpts from the secwatch advisory:

The vulnerability is due to an input validation error handling system default URIs with registered URI handlers such as "mailto", "news", "nntp", "snews" and "telnet". This can be exploited to execute arbitrary commands when a user e.g. using Firefox visits a malicious website with a specially crafted "mailto" URI containing a "%" character and ends in a certain extension (e.g. ".bat", ".cmd")

Confirmed on a fully patched Windows XP SP2 and Windows Server 2003 SP2 system using Firefox version 2.0.0.5 and Netscape Navigator version 9.0b2. Other versions and browsers may also be affected.

This is utter rubbish. ShellExecuteEx wasn't updated with IE 7.0. It is a core OS feature - on Windows XP SP2 systems the most recent update was in the MS07-006 security update.

All this function does is look up the URL protocol handler in the registry - for example, http: is at HKEY_CLASSES_ROOT\http - and look for the shell\open key. If a ddeexec key is found under that key, it uses DDE to send the URL to the registered program. If not, it runs the command under the command key, replacing the %1 in the command line with the URL to be processed.

IE uses ShellExecuteEx whenever it encounters a URL protocol it does not handle internally - basically only http:, https: and ftp:. The Windows Explorer 'Run' dialog calls ShellExecuteEx when you enter a URL into the dialog (in fact, when you enter *anything* into the dialog). It's how Explorer locates a program when you double-click a document file.

The question here is a difference of opinion over whether certain characters should be escaped in the command line or not. The behaviour of ShellExecute[Ex] has not changed. Microsoft are simply saying that Firefox has to cope with whatever it's presented with; Mozilla are saying it would be nice if certain characters were escaped.

[UPDATE:] I have since discovered that Internet Explorer decodes URL-encoded (%-encoded) characters and passes the decoded version to ShellExecuteEx. This allows an attacker to inject " characters into the command line, terminating the URL argument, and allowing further command line options to be specified.

The simplest workaround is to place a special command line option in first position (included in the command line in the registry, before "%1") that indicates that the rest of the command line came from a URL protocol handler and should be treated with caution.

• Affected OS: Windows
• Affected Browser(s): IE 7 + Firefox (together)
• Cert advisory: https://www.kb.cert.org/vuls/id/403150
• Secwatch advisory: http://secwatch.org/advisories/1018594/

Internet Explorer 7 has changed how Microsoft Windows parses URIs. This has introduced a flaw that can cause Windows to incorrectly determine the appropriate handler for the protocol specified in a URI. This flaw appears to rely on having a "%" character in the URI.

Publicly available exploit code uses Mozilla Firefox as an attack vector for this vulnerability. For more information, including workarounds, please see VU#783400

It seems that the injection mechanism is to use Firefox, but the exploit requires IE 7 to be installed on the victim's computer.

Interesting excerpts from the secwatch advisory:

The vulnerability is due to an input validation error handling system default URIs with registered URI handlers such as "mailto", "news", "nntp", "snews" and "telnet". This can be exploited to execute arbitrary commands when a user e.g. using Firefox visits a malicious website with a specially crafted "mailto" URI containing a "%" character and ends in a certain extension (e.g. ".bat", ".cmd")

Confirmed on a fully patched Windows XP SP2 and Windows Server 2003 SP2 system using Firefox version 2.0.0.5 and Netscape Navigator version 9.0b2. Other versions and browsers may also be affected.

This is utter rubbish. ShellExecuteEx wasn't updated with IE 7.0. It is a core OS feature - on Windows XP SP2 systems the most recent update was in the MS07-006 security update.

All this function does is look up the URL protocol handler in the registry - for example, http: is at HKEY_CLASSES_ROOT\http - and look for the shell\open key. If a ddeexec key is found under that key, it uses DDE to send the URL to the registered program. If not, it runs the command under the command key, replacing the %1 in the command line with the URL to be processed.

IE uses ShellExecuteEx whenever it encounters a URL protocol it does not handle internally - basically only http:, https: and ftp:. The Windows Explorer 'Run' dialog calls ShellExecuteEx when you enter a URL into the dialog (in fact, when you enter *anything* into the dialog). It's how Explorer locates a program when you double-click a document file.

The question here is a difference of opinion over whether certain characters should be escaped in the command line or not. The behaviour of ShellExecute[Ex] has not changed. Microsoft are simply saying that Firefox has to cope with whatever it's presented with; Mozilla are saying it would be nice if certain characters were escaped.

[UPDATE:] I have since discovered that Internet Explorer decodes URL-encoded (%-encoded) characters and passes the decoded version to ShellExecuteEx. This allows an attacker to inject " characters into the command line, terminating the URL argument, and allowing further command line options to be specified.

The simplest workaround is to place a special command line option in first position (included in the command line in the registry, before "%1") that indicates that the rest of the command line came from a URL protocol handler and should be treated with caution.

> Seriously, here's a phone. Call someone who cares. Or at least isn't surprised. Or at least thinks it's newsworthy.

Attitudes like this are why computer security is in such a dismal state. Crashing an application from a remote system means that application is not filtering it's input correctly and is subject to a remote compromise. Just because IE goes bu-bye and starts right up again doesn't mean everything is peaches. By the time you've restarted the app or rebooted windows, you may have already been compromised with the software of choice by the remote. This cold be a backdoor, keylogger, trojan whatever - and you won't even know it other than "my computer is slow". People need to wise-up because malware is getting sneakier and more cost effective for the people that write it.

Articles like this are news worthy because it brings light to the fact that something is amiss and needs fixing. Unfortunately, other than negative PR, there's little incentive for proprietary software to fix these things. That's one of the reasons IE has been, and still is, such a security nightmare. Firefox is only about 2/3 better (3 pages vs. 8 pages) judging by number of CVEs*. Still, security is about lessening risk. It's foolish to use IE these days with much better options available.

[*] - https://www.kb.cert.org/vuls/html/search

"If market share is any indication to being pwned; then why isn't Apache attacked more that IIS? According to Netcraft Apache has 53.76% of the market compared to MS: 31.83%"

Do tell, when was the last remote IIS worm?
From what Google says, it appears to be http://www.cert.org/advisories/CA-2001-11.html . 2001. Hmm...

No, Trusted Solaris and Solaris 10 with Trusted Extensions would not have been vulnerable to that vuln. And, did you know that MIT Kerberos distributions (which include a telnet daemon) also had a very similar hole ? So, basically ANY site that was running MIT kerberos with telnet enabled - Linux, BSD, etc) were also vulnerable to the same attack. MIT Kerberos is included in RH Linux and many other Linux distros as well. http://www.kb.cert.org/vuls/id/220816

The advice given to home users (and this) is clearly Windows specific, even though Windows is not mentioned. They go through the usual laundry list of things which are failing corporate users, firewalls, "patches", anti-virus and so on and so forth. Way down in the glossary is a mention of "Linux" linked to the "webopedia".

As I said before, these are important first steps. The information presented may be useful to novice computer users, but it's incomplete because it does not include some of the most effective options. We can only hope they follow up on this start.

The advice given to home users (and this) is clearly Windows specific, even though Windows is not mentioned. They go through the usual laundry list of things which are failing corporate users, firewalls, "patches", anti-virus and so on and so forth. Way down in the glossary is a mention of "Linux" linked to the "webopedia".

As I said before, these are important first steps. The information presented may be useful to novice computer users, but it's incomplete because it does not include some of the most effective options. We can only hope they follow up on this start.

Amit Klein has reported a vulnerability in Microsoft Windows, which can be exploited by malicious people to cause a DoS (Denial of Service).

The vulnerability is caused due to the WebDAV XML Message Handler not limiting the number of attributes that can be specified in an XML element. This can be exploited through Internet Information Services by sending a specially crafted WebDAV PROPFIND request.

Successful exploitation causes the WebDAV XML Message Handler to consume all CPU resources for a period of time.

Yes, without a doubt, there is code in Vista that in unchanged since the first version of NT and I suspect snippets of vulnerable Win9x code is still in there too. Scary, huh?

Without a doubt, there are code snippets on Unix, Linux and BSD systems that date back 30 years or more. How long has telnet been around? Sendmail? BIND? X? Assuming all that really, really old code is free from vulnerabilites simply because it is old is absolute folly.

I'm talking more poor applet security than poor Java desktop security. Java 6 makes Java *applications* sizzle. But for applets...

1) Poor auto-update features for client-side JVM (People do not tend to update their Java client JVM)
2) A vulnerability in the JDK or Java plugin may move all your clients into the attackable surface
3) Older JVM's (in the past) could force the application to use an older vulnerable JVM if installed
4) Stuff like java.lang.Runtime().getRuntime().exec("cmd.exe")
5) 2006 hall of fame!
http://www.kb.cert.org/vuls/id/759996
http://www.securityfocus.com/bid/17981
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4396719
Intesting tidbit:
http://www.securityfocus.com/archive/1/434001

PS: Consider taking http://www.sans.org/ns2007/description.php?tid=447

1) Don't contribute to the problem. Attacking botrunners directly, or vigilante action doesn't help, and may actually be harmful - by teaching them how to build better drones. See http://fm.vix.com/internet/security/superbugs.html

2) As for US gov't agencies, if you or the attacker seem to be in the US, http://www.ic3.gov/ is likely to be interested. http://www.cert.org/csirts/national/contact.html can also put you in touch with nationial computer security incident response teams, who will also be interested (you only need to contact the one local to you, please don't shotgun complaints to all of them.)

3) As for private companies and research organizations, if the bot isn't already clearly and specifically detected by antivirus, report it to them, following their reporting guidelines. Shadowserver (http://www.shadowserver.org) seems to be interested in researching and gathering intelligence on botnets also.

Unfortunately, the term Denial of Service is extremely vague and broad. Basically to the point of being useless.

http://www.cert.org/tech_tips/denial_of_service.ht ml

As far as I can tell, I'm technically committing a DoS attack if I steal your keyboard.

I think that most people reserve it for attacks against shared resources, or at least require that some abstract resource (such as disk space or bandwidth) is consumed. Otherwise, anything that I do to disrupt you from doing anything with your computer is a denial of service.

. Heck right my ssh port is open go ahead and try to crack it.

When Windows Explorer is configured to use the "Show common tasks in folders" option, HTML within a file may be processed when that file is selected. If the "Show common tasks in folders" is enabled, selecting a specially crafted HTML document in Windows Explorer may trigger this vulnerability. Note that the "Show common tasks in folders" is enabled by default. To mitigate this attack vector, enable the "Use Windows classic folders" option.

Have you patched your Norton Antivirus on your Windows servers? If not, you might want to read this http://www.kb.cert.org/vuls/id/404910/.

Netcraft and Secunia confirms it!

At 58.7%, Apache 2 had 33.
At 31.0%, IIS 6 had 3.

Those were vulnerabilities reported since 2003, or 11 and 1 per year, respectively. That would seem to suggest market share does correlate.

However, using the CERT vulnerability database dating back to 2000:

IIS gets around 22 and Apache almost 30.

Conclusion? Apache has predictably shown more vulnerabilities than IIS versions over the same time period, correlating a direct market share to vulnerability relationship (although not in strictly 1:1 proportions). Prior to 6 revs of IIS show it's crap vs. Apache. However, recent revisions to IIS show a *substantial* decrease in that proportion of market share to vulnerabilities, which Apache has not shown.

Netcraft and Secunia confirms it!

At 58.7%, Apache 2 had 33.
At 31.0%, IIS 6 had 3.

Those were vulnerabilities reported since 2003, or 11 and 1 per year, respectively. That would seem to suggest market share does correlate.

However, using the CERT vulnerability database dating back to 2000:

IIS gets around 22 and Apache almost 30.

Conclusion? Apache has predictably shown more vulnerabilities than IIS versions over the same time period, correlating a direct market share to vulnerability relationship (although not in strictly 1:1 proportions). Prior to 6 revs of IIS show it's crap vs. Apache. However, recent revisions to IIS show a *substantial* decrease in that proportion of market share to vulnerabilities, which Apache has not shown.

...I fell over laughing while reading this. (Go to slide 31)

Not quite. Only around 20% of registered, reported attacks come from an insider threat, and of those, only 10% are from IT. You can find this at a Jan 23rd posting on CERT about insider threats.

http://www.cert.org/

  Therefore, implying that the insider threat looms as large as others is highly divisive and misleading. Further, you can take concrete steps to reduce the risk of an insider threat, while you cannot have that level of impact in threat reduction (vulnerability and asset risk reduction, yes, but not threat) for the rest of the world.

- musides

The wireless exploit you cite, for example, turned out to be hype about a problem that affected no mac in its default state...

The wireless exploit did apply to Airport cards; but you are correct that researchers mishandled the disclosure - which, as I said, resulted in a lot of hard feelings on both sides.

Are all the analysts that came in contact with the disk drive in question certified forensic analysts, and if so by whom?
http://www.cert.org/certification/IHcertification_ faq.html
Was the disk drive ever out of your possession?
Who handed you the drive and what paperwork did you sign?
Are all their tools "certified" for forensic analysis?
Was the drive mounted "read only" so that no contamination could occur?
When on what day did they last test their own forensic analysis computers for rootkits?
Did they perform those same rootkit tests on the disk drive in question?
Where is the certification for their forensic computer systems?
Have these machines ever been used for any task other than forensic analysis?
Was the disk drive checksummed both before and after the analysis to prove it was not tampered with?

Even the company name has been chosen to be conflated with CERT. What a bunch of bollox.

Countdown to the phisher finding a way to subvert the system and obtain legitimate certs to green-light their scam sites :
4... 3... 2... 1...

Countdown to the phisher finding a way to subvert the system and obtain legitimate certs to green-light their scam sites :
4... 3... 2... 1...

I thought this was a bad thing.

For example, there was this http://www.kb.cert.org/vuls/id/175500 compromise from last year. I don't know the status, but it just seems to me this isn't such a good idea.

I can think of a few other reasons why taking the Microsoft approach to a firewall distro isn't good. Most of which boil down to Linux's current status as "more secure" is easily discredited.

An analogy would be all of the features/applications are a long rope with which the distro hangs itself.

I'm thinking the firewall needs to be very hardended with logging information to monitoring tools on another box. Am I wrong?

Amazing that this is news, yet the current serious DMG security problem presently affecting OSX does not appear on /. at all, not even buried in the Apple section. Strange huh? Even the BBC is reporting on it.

The Register is reporting that Apple have released some security updates, yet the DMG issue is unpatched.

/. positive OSX bias? Shurely not.

How about the CERT home security guide?

http://www.cert.org/homeusers/HomeComputerSecurity /

It even has a nice PDF version, on that page, if they want to read it off-line.
It doesn't cover all the things you wanted, but you might start with that, and write some more along that style?

Because every now and then there's a vulnerability in PNG.

Hacked by Chinese!

This vulnerability affects all Sun systems with microphones. This includes all versions of SunOS 4.1.x including 4.1.1, 4.1.2, 4.1.3, 4.1.3c, and all versions of Solaris 2.x including Solaris 2.1 (SunOS 5.1) and Solaris 2.2 (SunOS 5.2). Sun is addressing this problem in Solaris 2.3.

/dev/audio is set to a default mode of 666. There is also no indication to the user of the system that the microphone is on.

Any user with access to the system can eavesdrop on conversations held in the vicinity of the microphone.
...

Just because MS get the publicity for security holes, don't pretend other software doesn't have security holes.

For example,
http://www.kb.cert.org/vuls/id/866300
http://www.kb.cert.org/vuls/id/911004

Just because MS get the publicity for security holes, don't pretend other software doesn't have security holes.

For example,
http://www.kb.cert.org/vuls/id/866300
http://www.kb.cert.org/vuls/id/911004

And why isn't the government's warning message included with specific reasons and details of what the problems are and what the patch is going to do?

Why now?

Date Public 03/18/2005 A buffer overflow vulnerability in the McAfee Virus Scan Engine may allow a remote attacker to execute arbitrary code on an affected system. Because the vulnerability exists in a core component, a number of different McAfee products are affected. http://www.kb.cert.org/vuls/id/361180

I'm on a couple of these kinds of lists already.

I've been on the the CERT lists (and the Old system for 9 years now, and they have never abused the system to my knowledge. Granted, CERT is only for computers, but it is similar to some of the new proposed lists.

I also signed up for the Safe Community Alert Network, which is some sort of private-public partnership between SBC/ATT & various other organizations. Various government State, County & City agencies in California have referred me to ScanUSA.

ScanUSA does send me Amber Alerts, notifications about nearby fires, etc. However some of those Amber Alerts & Fire Alerts are from San Diego, which is 500 miles from me. Not very relevant.

The vast majority of the messages have been spam-ish -- I got notifications about the COPS program (COPS uses *very* agressive fundraising techniques), non-urgent warnings regardiing West Nile Virus, reminding me to wear sunscreen, and notifications about upcoming meeting for the County Health Department.

Here's the kicker: I'm only signed up for "Critical" alerts. I shouldn't be getting any of these--- but I do.

I would never sign up for SMS alerts from this organization. Way too much Spam.

Using HTTPS should be safe; it provides encryption so your password won't be sniffed on the wire as you log in. What you have to be careful about is whether you are in fact being connected to the server you think you are. If you are tricked into logging in to a fake site then encrypting your password in transit won't help.

This is where certificates come into play. A site like www.paypal.com will use a certificate that's signed by a widely recognized Certificate Authority (such as Verisign). Your browser will trust the site because (by default) it trusts the CA. If someone tries to fake it I would expect one of three things to happen:

1. The fake site could use plain HTTP instead of HTTPS, hoping that most people won't notice.
2. The fake site could use HTTPS with a self-signed certificate, in which case your browser would prompt you whether or not to trust it.
3. The fake site could use a certificate bought from a trusted CA, in which case you wouldn't know anything is wrong.

Scenario (3) would mean that they had to give some credentials to the CA when obtaining their certificate, so there is some accountability in theory. Also, I'd like to think that the CA wouldn't sign a fraudulent certificate for www.paypal.com but there is precedent for mistakes being made.

This has happened, yes. Actually there are currently remote LOCALSYSTEM exploits out for Symantec AV Corporate and Symantec Client security. Looking back numerous big-name AVs and personal firewalls were vulnerable to 'shatter' attacks and vulnerabilities are still occassionally discovered in unpacking engines (usually just "zip bomb" type DoS but not always).

My all-time favourite exploit was for ThunderByte AV; this had strong heuristics and ran well on the lowly 486's of the era, but it achieved this by basically running the code(!) in a sandbox. I think it was 29A that worked this out and managed to bypass it, resulting in a virus that got executed by ThunderByte itself every time it was scanned :)

Then there was that release of Norton that wouldn't execute WIN.COM anymore if you turned the 'bloodhound' heuristics all the way up, thereby preventing windows from starting ...

• A security alert from March of 2003 in which Sendmail has been determined to contain a buffer overflow vulnerability.
• Another security alert from later that year.
• A security alert also from 2003 regarding a remote buffer overflow.
• A security alert from 2002 regarding a trojan horse horse sendmail distro.
• Some freebsd specific Sendmail alerts.
• A security alert from March of 2006 (this year) regarding a race condition that may allow remote code execution by an arbitrary user.
• A plethera of similar or smaller security concerns can easily be found.
• The most recent release of Sendmail involves things like fixing possible integer overflows & unsafe use of setjmp(3)/longjmp(3) or adding time outs.

• A security alert from March of 2003 in which Sendmail has been determined to contain a buffer overflow vulnerability.
• Another security alert from later that year.
• A security alert also from 2003 regarding a remote buffer overflow.
• A security alert from 2002 regarding a trojan horse horse sendmail distro.
• Some freebsd specific Sendmail alerts.
• A security alert from March of 2006 (this year) regarding a race condition that may allow remote code execution by an arbitrary user.
• A plethera of similar or smaller security concerns can easily be found.
• The most recent release of Sendmail involves things like fixing possible integer overflows & unsafe use of setjmp(3)/longjmp(3) or adding time outs.