[quote]Mercury will presumably blacklist the IP of the local proxy, causing itself to not receive any mail anymore for the time of the short-term blacklisting (30 minutes AFAIK).[/quote]

Good point.  I'll watch out for that.

Of course, I would rather have the patch out now than wait for all the bells and whistles.

This was just posted at http://www.securityfocus.com/bid/25357.

Anything to worry about and is a patch in the works?

Thanks for any info!

[quote user="hawk"]

This was just posted at http://www.securityfocus.com/bid/25357.

Anything to worry about and is a patch in the works?

Thanks for any info!

[/quote]

I would say: of course there's a lot to worry:

Mercury Mail Transport System is prone to a remote stack-based

buffer-overflow vulnerability because it fails to perform adequate

boundary checks on when handling AUTH CRAM-MD5 requests.

Attackers

can exploit this issue to execute arbitrary code with the privileges of

the user running the application. Successful exploits will compromise

the computer. Failed exploit attempts will result in a denial of

service.

[quote user="HellasGuy"][quote user="hawk"]

This was just posted at http://www.securityfocus.com/bid/25357.

Anything to worry about and is a patch in the works?

[/quote]

I would say: of course there's a lot to worry:

Mercury Mail Transport System is prone to a remote stack-based

buffer-overflow vulnerability because it fails to perform adequate

boundary checks on when handling AUTH CRAM-MD5 requests. Attackers

can exploit this issue to execute arbitrary code with the privileges of

the user running the application. Successful exploits will compromise

the computer. Failed exploit attempts will result in a denial of

service.

 [/quote]

Yes, saw that, but in which context is an AUTH CRAM-MD5 request used?

 It could be that I'm not even using that module.
 

[quote user="hawk"][quote user="HellasGuy"][quote user="hawk"]

This was just posted at http://www.securityfocus.com/bid/25357.

Anything to worry about and is a patch in the works?

[/quote]

I would say: of course there's a lot to worry:

Mercury Mail Transport System is prone to a remote stack-based

buffer-overflow vulnerability because it fails to perform adequate

boundary checks on when handling AUTH CRAM-MD5 requests. Attackers

can exploit this issue to execute arbitrary code with the privileges of

the user running the application. Successful exploits will compromise

the computer. Failed exploit attempts will result in a denial of

service.

 [/quote]

Yes, saw that, but in which context is an AUTH CRAM-MD5 request used?

 It could be that I'm not even using that module. 

[/quote]

Sorry to be quoting myself. A quick google indicates this is used in SMTP-AUTH.

Further information from the Mercury manual:

Mercury supports an Internet standard called Authenticated SMTP (RFC 2554): when this
feature is enabled, Mercury will advertise to connecting clients that it can accept SMTP authentication.
If a client then authenticates correctly, it will be allowed to relay. Pegasus Mail
v3.12 and other widely-used Internet mail clients support authenticated SMTP, and it is an
excellent way of allowing your roving users to use your server without opening yourself to
relay abuse. Mercury supports three Authentication methods - CRAM-MD5, PLAIN and LOGIN,
although PLAIN and LOGIN are very weak and you should avoid clients that use them if possible.

Anyone that does not actually need this option (Configuration / SMTP Server / Connection control) should probably make sure it's switched off until a patch is available.

/Rolf
 

[quote user="Rolf Lindby"]

Anyone that does not actually need this option (Configuration / SMTP Server / Connection control) should probably make sure it's switched off until a patch is available.

/Rolf

[/quote]

I strongly doubt that this would have any effect. Those controls decide about relaying permission for authenticated users, but not about whether the AUTH things are still called anyways. The technical internals are probably up to David only.

As you say only David knows the technical details. The wording in the manual does however suggest that it might have an affect if this is switched on or not ("when this
feature is enabled, Mercury will advertise to connecting clients that it can accept SMTP authentication"). When in doubt I would go with the potentially safer option.

/Rolf 

[quote user="Rolf Lindby"]

As you say only David knows the technical details. The wording in the manual does however suggest that it might have an affect if this is switched on or not ("when this
feature is enabled, Mercury will advertise to connecting clients that it can accept SMTP authentication"). When in doubt I would go with the potentially safer option.

/Rolf 

[/quote]

Rolf,

my comment rather pointed to the fact that there's nothing worse than make people feeling in potentially false safety, what's definitely the case here.

For all those affected and concerned by this issue, but that can't take immediate countermeasures, I could offer a temporary mail redirection through my systems onto a different high number port of your Mercury until a patch is available. In such case please PM me directly for futher details. My systems are not affected by this issue as being very well protected.

This problem has been confirmed and patched, and the patch is now in urgent testing. I aim to release the amended code either tomorrow or Tuesday (my time).

Cheers!

-- David --

[quote user="David Harris"]

This problem has been confirmed and patched, and the patch is now in urgent testing. I aim to release the amended code either tomorrow or Tuesday (my time).

Cheers!

-- David --

[/quote]

David,

is the patch also tested against the Demo Exploit Pearl Script that's published on the Security Focus article linked in this thread?

[quote user="David Harris"]

This problem has been confirmed and patched, and the patch is now in urgent testing. I aim to release the amended code either tomorrow or Tuesday (my time).

Cheers!

-- David --

[/quote]

Thank you David for your quick response! In the meantime, is there any workaround that we may take to mitigate the problem?

Regards,

  Corrado
 

Thank you very much for that!

I tested the exploit code some on a spare machine and here is my assessment:

• As a Denial of Service at least, it works.  Mercury/32 crashes immediatly.  I do not believe the "Proof of Concept" code posted on SecurityFocus was meant to actually do anything more than crash the Mercury/32 process, it simply sends the phrase QUFB to the server 10,000 times causing Mercury to crash.  However, it is likely that someone could figure out where this memory is being placed and use the exploit to gain control of the Mercury server, they would have access to everything the user who executes the Mercury/32 process does.
• There does not appear to be a workaround at this point as it is not possible to prevent Mercury/32 from accepting CRAM-MD5 authentication attempts.  This is unfortunate since, in Novell environments at least, CRAM-MD5 logins won't succeed because there's no way to retrieve the plaintext or hashed password from NDS.  The ability to disable certain login methods would be useful in future versions of Mercury/32. 
  
• If you don't need the entire Internet to be able to connect to MercuryS in order to relay mail, you should definitely go to a deny by default in Connection Control and allow connections only from the few servers you need.
  
• The PoC exploit code uses an SMTP connection, however I believe CRAM-MD5 authentication is used in POP3 and IMAP also, these avenues should be explored also for patching.
• Both software and hardware DEP in Windows XP and Server 2003 seem to catch and block the buffer overflow.  If you're not running Mercury/32 on a box with an Intel processor capable of XD or an AMD processor capable of NX you should be.  Also, to make sure Mercury/32 is actually protected you should right click on My Computer, chose Properties, Advanced, Performance Settings and under the  Data Execute Protection Tab, verify that "Turn on DEP for All Programs..." is selected and Mercury/32 is not listed as an exception.  DEP might not be a fullproof workaround and the exploit will still crash Mercury/32 but it certainly will make things harder for hackers.

HellasGuy wrote: is the patch also tested against the Demo Exploit Pearl Script

that's published on the Security Focus article linked in this thread?

I have tested a beta of David's update against the published exploit, as have others, and the exploit fails against the patched/updated system.  The update not only fixes the vulnerability, but also adds detection that an exploit attempt has occurred and responds by adding the "attacking" IP address to the short-term blacklist.

[quote user="Nick FitzGerald"]

The update not only fixes the vulnerability, but also adds detection that an exploit attempt has occurred and responds by adding the "attacking" IP address to the short-term blacklist.

[quote user="tBB"]
Hmmm...this should perhaps be configurable because, if the user has some kind of anti-spam proxy installed like ASSP, Hermes, Spambunker etc. Mercury will presumably blacklist the IP of the local proxy, causing itself to not receive any mail anymore for the time of the short-term blacklisting (30 minutes AFAIK). This would be basically another DOS, wouldn't it?

Best regards

Nico
[/quote]

SpamBunker-protected mailservers are not at all affected by this whole vulnerability issue, no matter if Mercury is patched or not. And therefore such blacklisting mechanism would never be triggered on the Mercury, as the exploit cannot reach it anyways.

The only exception would be, if the Mercury SMTP port is exposed to the public internet directly. But in this case, such blacklisting does not affect SpamBunker either and is absolutely fine then, as it would hit the correct source IP. 

Then skip spambunker from the examples. I was assuming it's a transparent proxy like the other two mentioned in which case something like this will happen if the original exploit POC is used:

Connection from <local proxy IP>, Mon Aug 20 17:34:01 2007
EHLO you
AUTH CRAM-MD5
Buffer overflow attack attempted by <local proxy IP>
3 sec. elapsed, connection closed Mon Aug 20 17:34:04 2007

Best regards

Nico