Bug 11090 - nmap new security issue fixed in 6.40 (CVE-2013-4885)
Summary: nmap new security issue fixed in 6.40 (CVE-2013-4885)
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 3
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/565087/
Whiteboard: mga3-64-ok mga3-32-ok has_procedure
Keywords: Triaged, validated_update
Depends on:
Reported: 2013-08-27 17:29 CEST by Paul Blackburn
Modified: 2013-10-17 22:02 CEST (History)
5 users (show)

See Also:
Source RPM: nmap
Status comment:


Description Paul Blackburn 2013-08-27 17:29:31 CEST
ref: http://seclists.org/nmap-announce/2013/1

"From: Fyodor <fyodor () nmap org>
Date: Mon, 19 Aug 2013 14:50:05 -0700
Hi Folks.  It has been a while since the last stable Nmap release, but
I'm pleased to release Nmap 6.40 and I think you'll consider it worth
the wait!"
Comment 1 Manuel Hiebel 2013-08-27 18:59:06 CEST
looks like there is no security fix, usualy we don't update such package which could bring new bugs, let see that which maintainer

Keywords: (none) => Triaged
Component: New RPM package request => RPM Packages
Assignee: bugsquad => guillomovitch
Summary: Nmap 6.40 Released => update Nmap to 6.40 release
Source RPM: (none) => nmap
Severity: normal => enhancement

Comment 2 Paul Blackburn 2013-08-27 20:12:17 CEST
I think this may be considered a security fix:

 o [NSE] Oops, there was a vulnerability in one of our 437 NSE scripts.  If
  you ran the (fortunately non-default) http-domino-enum-passwords script
  with the (fortunately also non-default) domino-enum-passwords.idpath
  parameter against a malicious server, it could cause an arbitrarily named
  file to to be written to the client system. Thanks to Trustwave researcher
  Piotr Duszynski for discovering and reporting the problem.  We've fixed
  that script, and also updated several other scripts to use a new
  stdnse.filename_escape function for extra safety. This breaks our record
  of never having a vulnerability in the 16 years that Nmap has existed, but
  that's still a fairly good run! [David, Fyodor]
(source: http://seclists.org/nmap-announce/2013/1 )
Comment 3 Manuel Hiebel 2013-08-27 20:24:37 CEST
indeed and a patch is available https://bugzilla.redhat.com/show_bug.cgi?id=995634 in case off

QA Contact: (none) => security
Severity: enhancement => normal

David Walser 2013-08-27 23:05:02 CEST

Component: RPM Packages => Security
Summary: update Nmap to 6.40 release => nmap new security issue fixed in 6.40 (CVE-2013-4885)

Comment 4 David Walser 2013-08-28 18:28:05 CEST
Fedora has issued an advisory for this on August 15:

There is also an upstream advisory, including PoC details:

URL: (none) => http://lwn.net/Vulnerabilities/565087/
CC: (none) => luigiwalser

Comment 5 Dave Hodgins 2013-08-28 19:49:57 CEST
Mageia 3 is not susceptible to the security bug.

It just returns
| http-domino-enum-passwords:   
|_  ERROR: Failed to process results

so testing of an update will be limited to ensuring nmap works.

CC: (none) => davidwhodgins

Comment 6 Guillaume Rousse 2013-09-01 16:23:08 CEST
I'm not convinced of the interest of an update, if there is no vulnerability... Anyway, I just submitted nmap-6.25-3.1.mga3 with fedora patch applied in updates_testing.
Comment 7 David Walser 2013-09-01 17:28:40 CEST
Maybe the PoC doesn't work or wasn't used correctly?

Is the Mageia 2 nmap package not vulnerable to this?
Comment 8 David Walser 2013-09-01 17:30:05 CEST
Thanks Guillaume, BTW!  :o)

Packages currently uploaded:

from nmap-6.25-3.1.mga3.src.rpm
Comment 9 David Walser 2013-10-04 18:43:52 CEST
Getting the PoC to work isn't just a matter of running a command, but also getting the server it's run against to deliver a certain response.  I'm not exactly sure how to get it to do that.  This is a low-severity issue, and re-diffing the patch for Mageia 2 appears to be non-trivial.  Let's update Mageia 3.


Updated nmap packages fix security vulnerability:

It is possible to write arbitrary files to a remote system, through a specially
crafted server response for NMAP http-domino-enum-passwords.nse script from
nmap before 6.40 (CVE-2013-4885).


Updated packages in core/updates_testing:

from nmap-6.25-3.1.mga3.src.rpm

CC: (none) => guillomovitch
Assignee: guillomovitch => qa-bugs

Comment 10 claire robinson 2013-10-07 15:08:47 CEST
Advisory 11090.adv uploaded to svn.
Comment 11 Paul Blackburn 2013-10-08 10:36:20 CEST
testing on x86_64 Mageia 3:

Comment 12 Paul Blackburn 2013-10-09 11:57:42 CEST
Tested on x86_64 Mageia 3:


This patched Nmap 6.25 seems to be working fine.

Unable to test the fix for the specific vulnerability discovered
by Piotr Duszynski because unable to recreate the following:

    "It is possible to write arbitrary files to a remote system, through a
     specially crafted server response for NMAP http-domino-enum-passwords.nse
     script (from the official Nmap repository)."
     [source: http://packetstormsecurity.com/files/122719/TWSL2013-025.txt ]

    "Remediation Steps:
     The vendor has released an official patch for this vulnerability.  It is
     recommended to upgrade to Nmap 6.40."
     [source: http://packetstormsecurity.com/files/122719/TWSL2013-025.txt ]

Alternatively, one may download Nmap 6.40 rpms from insecure.org.
Comment 13 claire robinson 2013-10-10 11:54:05 CEST
Thanks Paul, are you able to test i586 also?

Whiteboard: (none) => mga3-64-ok

Comment 14 claire robinson 2013-10-14 09:52:41 CEST
Testing complete mga3 32

# nmap -O 192.168.1.*

nmap-frontends tested with zenmap to perform an 'Intense scan'.

Validating. Advisory uploaded in comment 10.

Could sysadmin please push from 3 core/updates_testing to updates


Keywords: (none) => validated_update
Whiteboard: mga3-64-ok => mga3-64-ok mga3-32-ok has_procedure
CC: (none) => sysadmin-bugs

Comment 15 Thomas Backlund 2013-10-17 22:02:52 CEST
Update pushed:

CC: (none) => tmb
Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.