RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1344823 - ssl-enum-ciphers failed to load in portrule function
Summary: ssl-enum-ciphers failed to load in portrule function
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nmap
Version: 7.2
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Pavel Zhukov
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-11 09:05 UTC by Todd
Modified: 2018-11-16 17:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-16 16:06:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Todd 2016-06-11 09:05:14 UTC 
Dear Red Hat,

I am coming from the community: Scientific Linux 7.2

Nmap 6 that comes with the repos will not work correctly with certain scripts, such as  ssl-enum-ciphers.nse.  

For instance:

# rpm -qa \*nmap\*
nmap-frontend-6.40-7.el7.noarch
nmap-6.40-7.el7.x86_64
nmap-ncat-6.40-7.el7.x86_64

# nmap -p xxxx,yyyy -Pn --script ssl-enum-ciphers.nse 162.xxx.yyy.zzz

NSE: A thread for /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse failed to load in portrule function:
/usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:1071: attempt to call field 'version_intensity' (a nil value)
stack traceback:
    /usr/bin/../share/nmap/scripts/ssl-enum-ciphers.nse:1071: in function '?'
    /usr/bin/../share/nmap/nse_main.lua:425: in function </usr/bin/../share/nmap/nse_main.lua:423>


The solution is to upgrade to nmap 7.12.

Would you please move to nmap 7.12 or the latest version ASAP.  Here are the RPMs already rolled for you:

https://nmap.org/download.html
https://nmap.org/dist/nmap-7.12-1.x86_64.rpm

And, that breaks nmap-frontend (zenmap).  Would you also upgrade nmap-frontend to support nmap 7.12 as well.  It is an extremely handy tool.  Here are the RPMs already rolled for you:

https://nmap.org/download.html
https://nmap.org/dist/zenmap-7.12-1.noarch.rpm


Many thanks,
-T
Comment 1 Todd 2016-06-11 09:09:42 UTC 
I should have noted that the script error above was with the current version of ssl-enum-ciphers downloaded from nmap.  The current badly outdated ssl-enum-ciphers that ships EL7 does not give the above errors.  It also does precisely nothing when run.  So you can't check your TLS/RC4 errors that show up in external scan for Payment Card Industry (PCI) testing.
Comment 2 Todd 2016-06-11 09:12:24 UTC 
The version shipped with EL 7 of ssl-enum-ciphers when run with nmap 7.12 does work.  It just does nothing when run from nmap 6.40
Comment 4 Pavel Zhukov 2017-06-29 07:22:58 UTC 
Hello,
(In reply to Todd from comment #0)
> Would you please move to nmap 7.12 or the latest version ASAP.  Here are the
> RPMs already rolled for you:
Rebasing of the packages in Red Hat Enterprise Linux is something we try to avoid as it may break our users workflow. Can you please point out which commit/change fix the issue upstream and we'll consider backporting it. 
> 
> https://nmap.org/download.html
> https://nmap.org/dist/nmap-7.12-1.x86_64.rpm
> 
> And, that breaks nmap-frontend (zenmap).  Would you also upgrade
> nmap-frontend to support nmap 7.12 as well.  It is an extremely handy tool. 
> Here are the RPMs already rolled for you:
> 
> https://nmap.org/download.html
> https://nmap.org/dist/zenmap-7.12-1.noarch.rpm
Thank you for providing the links.
However zenmap is not part of Red Hat Enterprise Linux. I can suggest you to package it for EPEL [1] to make it available for RHEL users.

> 
> 
> Many thanks,
> -T

[1] https://fedoraproject.org/wiki/EPEL
Comment 6 Pavel Zhukov 2017-06-29 07:42:22 UTC 
(In reply to Pavel Zhukov from comment #4)

> Thank you for providing the links.
> However zenmap is not part of Red Hat Enterprise Linux. I can suggest you to
> package it for EPEL [1] to make it available for RHEL users.
Please ignore this part. Zenmap is available as part of nmap-frontend. Can you please explain why it's broken for you?
Comment 7 Todd 2017-06-29 15:56:57 UTC 
Hi Pavel,

When you are doing Payment Card Industry (PCI) scanning -- both internal
and external -- for vulnerabilities and exploits -- you MUST have the latest, or
close to the latest, version to insure you are catching and testing everything.

You also suffer a consider amount of derision and out right refusal to help from the nmap community as they consider you an out right idiot for not being up to date.

-T
Comment 10 Red Hat Bugzilla Rules Engine 2018-11-16 16:06:40 UTC 
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 11 Todd 2018-11-16 17:54:02 UTC 
No problem.  I upgraded to Fedora last January and that solved the issue.
Note You need to log in before you can comment on or make changes to this bug.