Closed gluesmith2021 closed 1 month ago
As a first step we could include fresh identifiers for the dhcpd (server) to identify it in s09 via cpe: "isc:dhcpd:version"
└─$ grep "cpe.*isc:dhcpd" external/nvd-json-data-feeds/* -r | wc -l
56
└─$ grep "cpe.*isc:dhcp_client" external/nvd-json-data-feeds/* -r | wc -l
4
For the server identification just isc:dhcp:
would work not too bad. As far as I can see most of the available CVEs are server related:
└─$ grep "cpe.*isc:dhcp:" external/nvd-json-data-feeds/* -r
This will not solve the main issue but will allow us to improve the detection in this area a little bit. What do you think?
Sounds like a fair solution to me. The vast majority of isc:dhcp
CVEs indeed apply to the server.
In practice, I see two cases:
isc:dhcp
. Sounds good to me:
isc:dhcp_client
), there will be no false postives/negatives overall. isc:dhcp
CVEs will go missing. Probably not that bad:
Thank you for your prompt response so far (here and in other PR/Issues). It's nice to see a very-actively maintained project.
Could you include the new identifiers in the config and provide the binaries for verification testing?
isc:dhcp
or isc:dhcpd
? isc:dhcp
has much more CVEs, but I just realized from your solution above that we can't have both.In the meantime, here are the two binary files.
Those are 32-bit ARM ELF. Running them with --version
and -help
(an unknown command but gives "help" anyway) gives:
isc-dhclient-4.3.4
Internet Systems Consortium DHCP Client 4.3.4
...
isc-dhcpd-4.3.4
Internet Systems Consortium DHCP Server 4.3.4
...
- I'm not sure what you mean by "include fresh identifiers for S09". In the current case, S09 can't identify either product.
sorry for the misunderstanding. S09 is the static analysis module for version detection. In comparison to that the modules s115 and s116 are doing dynamic analysis via qemu execution. Both are using the same config file. So, I would recommend to include the version identifiers into the config file and verify them afterwards with a default run of EMBA.
- Then, in config file, should that resolve to
isc:dhcp
orisc:dhcpd
?isc:dhcp
has much more CVEs, but I just realized from your solution above that we can't have both.
I think we need to deal with both of them.
In the meantime, here are the two binary files.
Those are 32-bit ARM ELF. Running them with
--version
and-help
(an unknown command but gives "help" anyway) gives:
is the EMBA s115 module able to get the help out of it?
isc-dhclient-4.3.4
Internet Systems Consortium DHCP Client 4.3.4 ...
isc-dhcpd-4.3.4
Internet Systems Consortium DHCP Server 4.3.4 ...
after a quick static check we can implement the following rules:
dhcpd -> multi_grep rule - see here
1st identifier:
└─$ strings dhcpd | grep -E "Internet Systems Consortium DHCP Server"
Internet Systems Consortium DHCP Server
2nd identifier (reflects the version)
└─$ strings dhcpd | grep -E "^[0-9]+\.[0-9]+\.[0-9]+$"
4.3.4
This should then give the rules like the following - please take a look and verify/fix them (these are more blind guesses)
dhcpd;multi_grep;ISC;'"^Internet Systems Consortium DHCP Server$"&&"^[0-9](\.[0-9]+)+?$";"sed -r 's/([0-9]+(\.[0-9]+)+?)/dhcpd:\1/'";
dhcpd;multi_grep;ISC;'"^Internet Systems Consortium DHCP Server$"&&"^[0-9](\.[0-9]+)+?$";"sed -r 's/([0-9]+(\.[0-9]+)+?)/dhcp:\1/'";
If the emulator also prints the version like the following
Internet Systems Consortium DHCP Server 4.3.4
we can include the additional rules for the emulator:
dhcp;no_static;ISC;'"^Internet Systems Consortium DHCP Server [0-9](\.[0-9]+)+?$";"sed -r 's/Internet Systems Consortium DHCP Server ([0-9]+(\.[0-9]+)+?)/dhcp:\1/'";
dhcpd;no_static;ISC;'"^Internet Systems Consortium DHCP Server [0-9](\.[0-9]+)+?$";"sed -r 's/Internet Systems Consortium DHCP Server ([0-9]+(\.[0-9]+)+?)/dhcpd:\1/'";
Does this makes sense for you?
I made a few tests (about one analysis per day, given the time it takes) and I'm getting results. I'll create a pull request when everything works. So far, I had to:
dhcp
and dhcpd
are not blacklisted by udhcpd
Then I had issues with F20. I noticed that the sed
replacement command sometimes replaces the string with vendor:product:version
(e.g.: isc:dhcp_client:\1
) but most often with product:version
only (e.g.: iptables:\1
). However, F20 can't cope well with the three part string. For example, it can find vulnerabilities for dhcp:4.3.4
but not isc:dhcp:4.3.4
. In the latter case, the first grep looks for ...*:4.3.4:*...
or *isc:4.3.4:*
which does return product names ending with isc
, not dhcp
.
So, before I remove all isc:
is sed expression
hmm ... we have identifiers in the format vendor:product:version:
but also product:version:
and F20 should be able to deal with both of them.
The short identifiers are somehow legacy but usually working quite well. The longer identifiers are the way to go. I think there are some parsing issues in the output of F20 or F50 which we need to address in the future. Nevertheless, the vulnerability identification should work with both (long and short). If there are issues we need to take a look at it. Do you have non working examples?
Indeed, F20 fails to retrieve CVEs for isc:dhcp:version
as with its first grep to get potential CVE, it searches for either the exact version, or :.*${BIN_NAME}:\*:
. In that case, BIN_NAME is extracted as isc
, not dhcp
. Therefore it gets any product name that "ends with isc
".
Oddly enough, F20 handles and remove vendor name in other cases, such as in its log for CVE search.
In other words, looking at F20 log:
isc:dhcp
in sed replacement:[+] Found Version details (aggregated): isc:dhcp:4.3.4
...
[*] Vulnerability details for dhcp / version 4.3.4 / source UEMU:
[-] Found NO CVEs and NO exploits (including POC's) in dhcp with version 4.3.4 (source UEMU).
dhcp
only in sed replacement, it finds 4 correct vulnerabilities:[+] Found Version details (aggregated): dhcp:4.3.4
...
[*] Vulnerability details for dhcp / version 4.3.4 / source UEMU:
[0;32m BIN NAME : BIN VERS : CVE ID : CVSS VALUE : EPSS : SOURCE : EXPLOIT[0m
[0;31m dhcp : 4.3.4 : CVE-2017-3144 : 7.5 : NA : UEMU : No exploit available[0m
[0;31m dhcp : 4.3.4 : CVE-2018-5732 : 7.5 : NA : UEMU : No exploit available[0m
[0;31m dhcp : 4.3.4 : CVE-2018-5733 : 7.5 : NA : UEMU : No exploit available[0m
[0;33m dhcp : 4.3.4 : CVE-2022-2929 : 6.5 : NA : UEMU : No exploit available[0m
[+] Found 4 CVEs and 0 exploits (including POC's) in dhcp with version 4.3.4 (source UEMU).
Thx for testing ... I need to check this.
sorry for the delay and lack of intense tests. As I'm out of office I have just limited time ... Currently I'm just poking around and trying to reproduce the issue between long and short version identifier
Indeed, F20 fails to retrieve CVEs for
isc:dhcp:version
as with its first grep to get potential CVE, it searches for either the exact version, or:.*${BIN_NAME}:\*:
. In that case, BIN_NAME is extracted asisc
, notdhcp
. Therefore it gets any product name that "ends withisc
".
The following should extract the version: https://github.com/e-m-b-a/emba/blob/c590aeed484760499b7938a209f55df8c59101ca/modules/F20_vul_aggregator.sh#L621
ASDF="isc:dhcpd:4.3.4:"
└─$ echo "${ASDF%:}" | rev | cut -d':' -f1 | rev
4.3.4
looks good
Next it extracts the name: https://github.com/e-m-b-a/emba/blob/c590aeed484760499b7938a209f55df8c59101ca/modules/F20_vul_aggregator.sh#L623
└─$ echo "${ASDF%:}" | rev | cut -d':' -f2 | rev
dhcpd
looks also good
If we grep for the long identifier here https://github.com/e-m-b-a/emba/blob/c590aeed484760499b7938a209f55df8c59101ca/modules/F20_vul_aggregator.sh#L651 we have a vuln and log it. Otherwise we check for further criteria with the short name of binary which should be fine.
I think we are done for now. See you next time again :)
Is your feature request related to a problem? Please describe.
There are missing CVE in results for ISC DHCP Client/Server, and this is in part related to a cpe naming issue in NVD data.
In NVD database cpe strings,
isc:dhcp_client
CVEs seems to apply a DHCP "client", whileisc:dhcpd
CVEs apply to the server component instead. However, in many CVEs the stringisc:dhcp
is used instead, for both client and server components.For example, CVE-2018-5732 applies to the client, while CVE-2018-5733 apply to the server part. Both use
cpe:2.3:a:isc:dhcp:*:...
among others. Only the textual description allows to discriminate.The choice of one or the other might be related to the CVE year, since only a single name is used per year. Of course, that might be a mere coincidence as well:
dhcp_client
dhcpd
dhcp
dhcpd
dhcp
Describe the solution you'd like
First, EMBA could detect "ISC DHCP Server" as well, just like the client currently is.
Second, given that NVD DB does not discriminate between "client" and "server" in using
isc:dhcp
, EMBA could somehow aggreate CVEs using:isc:dhcp_client
andisc_dhcp
for the clientisc:dhcpd
andisc_dhcp
for the serverThis will brings false positives in aggregated CVEs, but the NVD database does not allow to discriminate better. Right now, we have false negatives (missing CVEs) given that EMBA only search for
dhcp_client
.Describe alternatives you've considered
Changing the string replacements in
bin_version_strings.cfg
as in original PR #1150 before changes were reverted. The string replacement mechanism alone does not allow for the above solution.Priority issue Are you already a Sponsor? N
Additional context
I had to analyze a firmware image that had both client and server DHCP binaries, and the identification string is straightforward. Version however is not detectable from S09 as it is not part of the identification string. S116 can detect it though. In my case, both were version 4.3.4 from 2016. EMBA would report
isc:dhcp_client
for the client, and not report the server at all. In both case, it misses the few CVEs that apply to that version:/sbin/dhclient
file:Internet Systems Consortium DHCP Client
/usr/sbin/dhcpd
file:Internet Systems Consortium DHCP Server
/sbin/dhclient
:Internet Systems Consortium DHCP Client 4.3.4
isc-dhclient-4.3.4