False identification of Adobe Reader on iLO device

OpenVAS is identifying all of our iLO cards (HP Lights-Out 100) as having Adobe Reader. The cards are very dumb, and do not even support installing software, let alone something like Adobe Reader. They’re not really even “modern” devices, although we do provide OpenVAS with SSH credentials to them.

They’re hardware version 1.0, firmware version 4.26, and list their description as DL160 G6, if that helps anyone somehow.

We show many medium and high Adobe vulnerabilities on these devices, with obviously bungled “Location” tags, making me think a parsing error has occurred in some CPE lister somewhere.

I know that …800108 is not an oid that carries risk, but I thought its output (two different firings of 800108 in the same scan) might be helpful in diagnosing why this is happening. Its output is below, and the descriptions are given exactly as they appear - mismatched quotes, trailing periods, and all (although indented for this forum):

From one:

port: general/tcp
qod value: 80
qod type: executable version
    Detected Adobe Reader

    Version:  7
    Location: /bin/sh -c 'LANG=C; LC_ALL=C; find "/" -maxdepth 7 -mindepth 1 \( -path "*/proc"
    CPE:      cpe:/a:adobe:acrobat_reader:7

    Concluded from version/product identification result:

From another:

port: general/tcp
qod value: 80
qod type: executable version
    Detected Adobe Reader

    Version:  .
    Location:  -o -path "/run" -o -path "/dev" -o -path "/sys" -o -path "/media" -o -path "/tm
    CPE:      cpe:/a:adobe:acrobat_reader:.

    Concluded from version/product identification result:

Does anyone have the faintest clue how to address this issue? Thanks in advance!

Thanks for your report and the detailed information provided. There seems to be indeed something uncommon on this iLO device so that the functions trying to find a file and extracting the information from it showns an unexpected behavior.

If you have the possibility and an installation with the openvas-nasl command line tool at hand it would be great if you could provide the output (please use a terminal with unlimited scrolling as it might be a longer output) either as an attachment here or via a direct message to me (if it contains too much sensitive data):

openvas-nasl -X -B -d -i /var/lib/openvas/plugins -t <target> --kb="Services/ssh=22" --kb="Secret/SSH/login=<username>" --kb="Secret/SSH/password=<password>" --kb="global_settings/ssh/debug=1" gather-package-list.nasl os_detection.nasl gb_unknown_os_service_reporting.nasl gb_adobe_prdts_detect_lin.nasl

Before running the command you might need to change into the /var/lib/openvas/plugins folder (path depends on your installation and might be adapted on your environment).

Thanks for your reply. Attached is the output of the command you provided. iLO-ov-output (13.4 KB)

Just a bit more background about the device, in case it helps. The prompt for the device is


and is not configurable. There is no /bin/sh, or any sh or bash anywhere for that matter. It’s a pretty rudimentary command line, and I think the only valid commands are “cd”, “version”, “exit”, “show”, and “help”.

The device does have a web console, which is how one manages it.

Note that the output is the same for all of our iLO devices (except of course the IP).

1 Like

Just realized stderr did not make it into that file. Attached is the output of that same command, but including stderr. iLO-ov-output-with-stderr (17.6 KB)

1 Like

Thanks again for your response and for providing such detailed information, this has helped quite a lot to understand whats happening here.

Two changes where made which should solve this seen issue:

  1. Basic detection of such an HP iLO device was implemented (stay tuned for an additional detection and version gathering script in the next few weeks). This also includes setting the internal information within the SSH implementation on NASL side to not launch VTs which requires linux/unix tools like find, cat etc. available on the target system.

  2. The Adobe Reader Detection script was updated to be less error prone once such unexpected responses are received.

Those changes have arrived the feed once the “Determine OS and list of installed packages via SSH login” VT (OID: has reached the feed with revision r13537.


Hi @cfi,

It seems this issue may have come up again, on a different class of devices. I’d like to run the command you gave me and post the output for advice, but SSH is running on a nonstandard port (37222). How do I inform openvas-nasl of that?


Thanks, additional output is always appreciated.

Basically it should be possible to append the following to the mentioned openvas-nasl call:


or replace the existing --kb="Services/ssh=22 to run the check against a non-standard SSH port.

Unfortunately the openvas-scanner function get_ssh_port (used by the NASL function ssh_connect) seems to not use this where it should and is always falling back to use the port 22.

I have raised an internal ticket to check why this is happening. For now the only possibility to use a different SSH port is to update the ssh_func.inc and change:

sess = ssh_connect();

in the function ssh_login_or_reuse_connection() to the following:

sess = ssh_connect(port:37222);

I’m slogging my way through trying to figure this out. Looks like OpenVAS is completing scans with this new device (a rudimentary *nix system much like the one from my original post above), and claiming it has Adobe software on it, which it does not. I’m running openvas-nasl with the kludge in ssh_func.inc, and with the arguments you suggested above:

 openvas-nasl -X -B -d -i /var/lib/openvas/plugins -t "" --kb="Secret/SSH/login=<username>" --kb="Secret/SSH/password=<password>" --kb="global_settings/ssh/debug=1" gather-package-list.nasl os_detection.nasl gb_unknown_os_service_reporting.nasl gb_adobe_prdts_detect_lin.nasl

but all I get back is

set key Host/runs_unixoide -> 1
No Best matching OS identified. Please see the NVT 'Unknown OS and Service Banner Reporting' (OID: for possible ways to identify this OS.

Forgive my lack of understanding here - what am I doing wrong that I get this result, but a full scan gives me much more information?

Besides that, the original problem still remains, that Adobe Reader is falsely identified on this device, at the following “location”, eerily similar to my original post:

 Detected Adobe Reader

 Version:  2.4.4
 Location: find "/" -maxdepth 7 -mindepth 1  ( -path "*/proc" -o -path "/run" -o -path "/dev" -o -path "/sys" -o -path "/me dia" -o -path "/tmp" -o -path "/var" ) -prune -o  -name "AcroVersion" -a  -type  f  -print 2&gt;/dev/null
 CPE:      cpe:/a:adobe:acrobat_reader:2.4.4

 Concluded from version/product identification result:

If anyone with more familiarity of the codebase wants to look at this, (@cfi?) I’d be happy to PM the xml output of a scan.

Thanks very much.

Mhhh, this is really strange. The call works for me (after hardcoded the non-default port in the ssh_func.inc) so not sure whats going on here.

As an alternative you could also do a “full” scan to gather the necessary information. For this you need to clone the “Full and Fast” scan config, go to the Network Vulnerability Test Preferences and change the setting “Enable SSH Debug” of the VT “Global variable settings” to “yes”.

Afterwards a full scan with this scan configuration should log the required information to the openvassd.dump (GVM-9 and below) / openvassd.log (GVM-10+). The location depends on your installation but should be somewhere in /var/log/openvas.

Again, thanks for providing all this info. :+1:

1 Like

Thanks @cfi, that did the trick. I’ve PM’d you the results of the scan. Would you be able to take a look and see why the scan is “finding” Adobe Reader, etc.? Let me know what you find if you don’t mind - I’d love to understand what’s going on as well.

PN received, thanks again for providing this information. Please stay tuned, will review the info next week and give some more background afterwards.

But basically the reason why this is happening was explained in some text in between previously:

The current SSH implementation is working in a way that it requires such systems not having a full linux shell available to be detected as such. As an example you can find the implementation for the HP iLO devices initially reported at around line 400 in the file gather-package-list.nasl.

Something similar is most likely required for this second system as well.

Thank you. Would it also be possible to have the package enumerator parse the return string for bogus values? For example, seems like if the check for Adobe Reader starts with find "/" -maxdepth 7 -mindepth 1 and the response also starts with find "/" -maxdepth 7 -mindepth 1, there might be some way to detect this as not actual evidence of Adobe Reader existing. Maybe some sort of heuristic comparison between the command and the response around line 2476 of ssh_func.inc? There’s other places it occurs, too, like whatever function generates the command

grep -o -m1 -a "[0-9]\+,[0-9]\+,[0-9]\+,[0-9]\+" find\ "/"\ -maxdepth\ 7\ -mindepth\ 1\ \ (\ -path\ "*/proc"\ -o\ -path\ "/run"\ -o\ -path\ "/dev"\ -o\ -path\ "/sys"\ -o\ -path\ "/me\ dia"\ -o\ -path\ "/tmp"\ -o\ -path\ "/var"\ )\ -prune\ -o\ \ -name\ "libflashplayer.so"\ -a\ \ \ -type\ f\ \ -print\ 2>/dev/null`

but I’ve not been able to find that one in the code.

This would probably eliminate lots of false positives in cases where the remote device’s operating system has not been correctly identified as lacking a full shell.

So this should be fixed in one of the next feed updates including some additional updates to the handling of such pfSense applications.

The main problem in this case wasn’t the handling of the device itself in the SSH functions but a used “tcsh” shell for that specific user which wasn’t handled correctly (by appending a /bin/sh to each command as usual).

Nevertheless from the above the suggestion on gracefully handle such bogus return values when searching for binaries was implemented as well.

1 Like

We continue to have this behavior on uncredentialed and IoT devices, currently seen on the following OID’s:


What can we do to assist in getting these dealt with once and for all?

While the outcome might be similar / the same the reason could be a completely different (like seen previously in comment #11 and comment #13).

To check where this newly reported issue is coming from it would be great to get another batch of logs like asked in comment #9.

Please note that those two VTs are checking for issues in web pages / services via an unauthenticated HTTP connection and are unrelated to this topic. These should be reviewed and mitigated accordingly.