search

the-tcpdump-group / libpcap

the LIBpcap interface to various kernel packet capture mechanism
https://www.tcpdump.org/
Other
2.66k stars 844 forks source link

CVE-2018-16301 information #855

Closed Beuc closed 2 years ago

Beuc commented 5 years ago

Hi,

I'm part of the Debian Long Term Support team, and I'd like to assess if our packaged versions of libpcap are affected by CVE-2018-16301.

81c4e00e says it relates to "errors in pcapng reading", but I cannot identify the related commit.

In addition, https://www.tcpdump.org/public-cve-list.txt doesn't list it as fixed, and marks it as affecting tcpdump rather than libpcap.

Can you link the specific fix? Regards,

mcr commented 4 years ago

Beuc notifications@github.com wrote:

I'm part of the Debian Long Term Support team, and I'd like to assess if our packaged versions of libpcap are affected by CVE-2018-16301.

Yes.

> 81c4e00e says it relates to "errors in pcapng reading", but I cannot
> identify the related commit.

> In addition, https://www.tcpdump.org/public-cve-list.txt doesn't list
> it as fixed, and marks it as affecting tcpdump rather than libpcap.

!A 2018-08-01 Include Security F1: [libpcap] Remote Packet Capture Daemon (RPCAPD) Integer Overflow Leads to Heap Buffer Overflow rpcapd/daemon.c:daemon_unpackapplyfilter(), fixed in 1.9 branch, not master, CVE-2019-15161

CVE-2018-16301 is, I think, a duplicate of CVE-2019-15161 (libpcap). It is fixed in 7f8d184f60bf3a228e3d17407dcc7c4a8689eb47. It is in rpcapd, which I think that Debian does not ship, and was not present in libpcap 1.8.x

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

Beuc commented 4 years ago

Thanks @mcr.

carnil commented 4 years ago

Hi,

On Sun, Oct 06, 2019 at 02:36:04AM -0700, Michael Richardson wrote:

Beuc notifications@github.com wrote:

I'm part of the Debian Long Term Support team, and I'd like to assess if our packaged versions of libpcap are affected by CVE-2018-16301.

Yes.

> 81c4e00e says it relates to "errors in pcapng reading", but I cannot
> identify the related commit.

> In addition, https://www.tcpdump.org/public-cve-list.txt doesn't list
> it as fixed, and marks it as affecting tcpdump rather than libpcap.

!A 2018-08-01 Include Security F1: [libpcap] Remote Packet Capture Daemon (RPCAPD) Integer Overflow Leads to Heap Buffer Overflow rpcapd/daemon.c:daemon_unpackapplyfilter(), fixed in 1.9 branch, not master, CVE-2019-15161

CVE-2018-16301 is, I think, a duplicate of CVE-2019-15161 (libpcap). It is fixed in 7f8d184f60bf3a228e3d17407dcc7c4a8689eb47. It is in rpcapd, which I think that Debian does not ship, and was not present in libpcap 1.8.x

But do you know the exact background behind this? I'm asking because I cannot find 7f8d184f60bf3a228e3d17407dcc7c4a8689eb47. CVE-2019-15161 and CVE-2018-16301 were distinctly assigned. CVE-2019-15161 on the ther hand was is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15161 associated with https://github.com/the-tcpdump-group/libpcap/commit/617b12c0339db4891d117b661982126c495439ea .

Information on CVE-2018-16301 seem to indicate that it first was thought to be an issue in tcpdump, but then it's clearly stated that it is fixed in libpcap.

The CVE description submitted to MITRE is as well inline with that:

libpcap before 1.9.1, as used in tcpdump before 4.9.3, has a buffer overflow and/or over-read because of errors in pcapng reading.

We have marked it now as such in Debian's records, but if CVE-2018-16301 is a duplicate of CVE-2019-15161 then preferably upstream would need to ask MITRE to reject CVE-2018-16301.

Regards, Salvatore

mcr commented 4 years ago

carnil notifications@github.com wrote:

Information on CVE-2018-16301 seem to indicate that it first was thought to be an issue in tcpdump, but then it's clearly stated that it is fixed in libpcap.

The CVE description submitted to MITRE is as well inline with that:

(okay, but don't use that as authoritative, since I am the one that wrote that)

>> libpcap before 1.9.1, as used in tcpdump before 4.9.3, has a buffer
>> overflow and/or over-read because of errors in pcapng reading.

> We have marked it now as such in Debian's records, but if
> CVE-2018-16301 is a duplicate of CVE-2019-15161 then preferably
> upstream would need to ask MITRE to reject CVE-2018-16301.

MITRE has a very poor record and very high latency for responding. I'm happy to get our records cleared up; I will be adding a "duplicates" column to my CSV file. I'm just still in a bit of PTSD from having worked on this stuff for too long :-(

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

stevebeattie commented 4 years ago

@carnil I think the commits listed as addressing CVE-2019-15165, namely a5a36d9e82dde7265e38fe1f87b7f11c461c29f6 and 87d6bef033062f969e70fa40c43dfd945d5a20ab, are actually the ones for CVE-2018-16301, since they actually touch sf-pcapng.c, and don't make any reference to "Include Security I8" as claimed in http://www.tcpdump.org/public-cve-list.txt .

I suspect CVE-2019-15165 is actually supposed to be fixed by 617b12c0339db4891d117b661982126c495439ea , since the commit message claims "This addresses Include Security issue I8: [libpcap] Remote Packet Capture Daemon Parameter Reuse."

Of course, that's the commit that's listed by tcpdump upstream as fixing CVE-2019-15161. But that CVE in http://www.tcpdump.org/public-cve-list.txt references "Include Security F1" which would seem to be addressed by 449d95265252b291711899fd288836414791930d which is not referenced at all in http://www.tcpdump.org/public-cve-list.txt but contains "It also addresses Include Security issue F1: [libpcap] Remote Packet Capture Daemon (RPCAPD) Integer Overflow Leads to Heap Buffer Overflow." in its commit message.

Previous attempts to get clarification were .... unsuccessful.

That said, for Debian's perspective, of the six listed CVEs against libpcap, only one of them actually affected debian packages, and that's addressed by the fixes to sf-pcapng.c.

guyharris commented 4 years ago

OK, here's a list of libpcap CVEs and the fixes in both the master and 1.9 branches.

CVE-2019-15161 - Include Security issue I8: [libpcap] Remote Packet Capture Daemon Parameter Reuse.

CVE-2019-15162 - fixes one of the sub-issues in Include Security issue F11: [libpcap] Remote Packet Capture Daemon Multiple Authentication Improvements

CVE-2019-15163 - Include Security issue F12: [libpcap] Remote Packet Capture Daemon Null Pointer Dereference Denial of Service

CVE-2019-15164 - Include Security issue F13: [libpcap] Remote Packet Capture Daemon Allows Opening Capture URLs

CVE-2019-15165 - not an Include Security issue; cleans up the error checks that make sure a pcapng block isn't too large before allocating memory for it - Michael, does this fix a malloc-fail or chew-up-the-entire-address-space-or-backing-store DoS, over and above what the existing code did?

CVE-2018-16301, however, appears to be misdescribed: the description on cve.mitre.org for that issue says it's a libpcap issue when reading pcapng files, but we appear to have intended to assign it to Include Security issue F2: [tcpdump] Integer Arithmetic Error can Lead to Heap Buffer Overflow When Processing Large Files is a tcpdump issue when reading a text file with 2^32-1 bytes in it containing a filter, as a result of the -F flag being given an argument referring to that file.

That one isn't fixed.

guyharris commented 4 years ago

There's also Include Security issue F1: [libpcap] Remote Packet Capture Daemon (RPCAPD) Integer Overflow Leads to Heap Buffer Overflow, which is fixed:

but doesn't appear to have a CVE assigned to it.

guyharris commented 4 years ago

As for Include Security issue F11: [libpcap] Remote Packet Capture Daemon Multiple Authentication Improvements, one of the sub-issues is fixed in the master branch by adding TLS support in the rpcap client and server - it requires libssl, and is a big change, probably inappropriate for backporting.

(It's also been an issue since the rpcap protocol was first introduced in WinPcap ages ago - the workaround is "don't use remote capture on a network where you don't want user names and passwords flying over your network".)

Another sub-issue is that the brute-forcing prevention should perhaps be more vigorous. Boosting the delay before we accept a new request after a username/password attempt failed with an invalid username or password would help; I'm not sure whether we should have a file to record that to handle brute-forcing by connect/authenticate/disconnect/connect again... or not.

guyharris commented 4 years ago

BTW, note that the only platform on which the default is to compile in the remote capture support is Windows; configuration needs to be done with --enable-remote using autotools, or with -DENABLE_REMOTE=YES using CMake, on UN*Xes to get the remote capture support.

Beuc commented 4 years ago

@guyharris would it be possible to request a new CVE for "Include Security issue F2" (ex-CVE-2018-16301), even if it's not fixed yet, since all distros now consider it fixed in libpcap?

In addition, "Include Security F1", which you noted doesn't have a CVE, is marked as fixed in https://www.tcpdump.org/public-cve-list.txt. I would recommend also requesting a CVE using the MITRE form as well.

So IIUC public-cve-list.txt would be clarified as:

ret2libc commented 4 years ago

Hi,

Sorry for asking again, but it is not clear to me what's the final answer.

Thank you all!

mcr commented 4 years ago

Riccardo Schirone notifications@github.com wrote:

Sorry for asking again, but it is not clear to me what's the final answer.

  • Is CVE-2018-16301 a real security flaw in libpcap?
  • If yes, is there a fix for it? Where?
  • If no, I can request MITRE to reject the CVE

We now have access to send them pull requests on CVE text, so it will be easier for us to do that.

ret2libc commented 4 years ago

Pull requests for what? Do you mean to MITRE? Could you provide the details for the above flaw here as well? MITRE could take some time to update texts. Thanks!

guyharris commented 4 years ago
  • Is CVE-2018-16301 a real security flaw in libpcap?

The description is "libpcap before 1.9.1, as used in tcpdump before 4.9.3, has a buffer overflow and/or over-read because of errors in pcapng reading".

The "as used in tcpdump before 4.9.3" is weird - libpcap bugs are largely libpcap bugs no matter what program uses them. There is an issue in tcpdump, wherein if you hand tcpdump a sufficiently large file with the -F flag ("sufficiently large" meaning "if you add 1 to its size, it won't fit in a u_int"), it will fail. That's reading a text file rather than a capture file, however.

I don't see any place where that's an issue in libpcap's pcapng reading code, even in 1.9.0.

So I'd say the answer is "no".

mcr commented 4 years ago

Guy Harris notifications@github.com wrote:

  • Is CVE-2018-16301 a real security flaw in libpcap?

The description is "libpcap before 1.9.1, as used in tcpdump before 4.9.3, has a buffer overflow and/or over-read because of errors in pcapng reading".

So, I asked MITRE about some of this text, as I many CVEs have descriptions which are close, but not identical to the commit message, and not text I provided.

I learnt that MITRE people will write up descriptions if the one is insufficient, and they are trained not reword in order not to violate copyright.

In the future, we will providing our own descriptions directly to them.

> The "as used in tcpdump before 4.9.3" is weird - libpcap bugs are
> largely libpcap bugs no matter what program uses them. There is an
> issue in tcpdump, wherein if you hand tcpdump a sufficiently large
> file with the -F flag ("sufficiently large" meaning "if you add 1 to
> its size, it won't fit in a u_int"), it will fail. That's reading a
> text file rather than a capture file, however.

> I don't see any place where that's an issue in libpcap's pcapng
> reading code, even in 1.9.0.

> So I'd say the answer is "no".

Agreed.

ret2libc commented 4 years ago

Thanks a lot to both of you @mcr and @guyharris !

carnil commented 4 years ago

@mcr, @guyharris, @ret2libc: When you say (in https://github.com/the-tcpdump-group/libpcap/issues/855#issuecomment-575665471), "There is an issue in tcpdump, wherein if you hand tcpdump a sufficiently large file with the -F flag ("sufficiently large" meaning "if you add 1 to its size, it won't fit in a u_int"), it will fail. That's reading a text file rather than a capture file, however." is then this one the one meant for CVE-2018-16301?

guyharris commented 4 years ago

@mcr, @guyharris, @ret2libc: When you say (in #855 (comment)), "There is an issue in tcpdump, wherein if you hand tcpdump a sufficiently large file with the -F flag ("sufficiently large" meaning "if you add 1 to its size, it won't fit in a u_int"), it will fail. That's reading a text file rather than a capture file, however." is then this one the one meant for CVE-2018-16301?

I don't know. It is a potential buffer over-read, and was one of the Include Security issues, but 1) it's not in the pcapng code and 2) it's not in libpcap, so it doesn't entirely match.

ret2libc commented 4 years ago

@mcr @guyharris Do you mind if I request a CVE rejection to MITRE? If the flaw does not exist in libpcap, there should be no CVE.

mcr commented 4 years ago

Riccardo Schirone notifications@github.com wrote:

@mcr @guyharris Do you mind if I request a CVE rejection to MITRE? If the flaw does not exist in libpcap, there should be no CVE.

We are supposed to demonstrate to MITRE that we can write things up right, so maybe I can just do that as homework? I'm happy to use your text.

ret2libc commented 4 years ago

@mcr Ok, thanks. I'm going to consider CVE-2018-16301 NOTABUG from now on.

maheshkukreja1 commented 4 years ago

Hi @ret2libc, was a rejection request submitted to MITRE for CVE-2018-16301? Any further updates on this particular CVE?

ret2libc commented 4 years ago

@maheshkukreja1 no I did not request a rejection and I don't have other updates unfortunately. @mcr ?

carnil commented 4 years ago

Looks the CVE got finally rejected, so this should be sorted out now.

infrastation commented 2 years ago

MITRE allocated CVE-2018-16301 on 2018-09-01 after I requested the allocation and provided the initial write-up. This was a follow-up to Include Security discovering and reporting the vulnerability (case reference "F2") as a work sponsored by Mozilla under MOSS SOS program. The vulnerability concerns a bug in tcpdump, Guy Harris eventually fixed the problem in commit the-tcpdump-group/tcpdump@faf8fb7, which became available in tcpdump release 4.99.0. Unfortunately, neither the commit message nor the change log referenced the problem properly.

The following should decomplicate this matter:

ret2libc commented 2 years ago

@infrastation could you explain the flaw here better please?

infrastation commented 2 years ago

The change logs and the web site have been corrected. The CVE content correction is pending as CVEProject/cvelist#4427. Please see the earlier comments starting on 2019-11-22 and the JSON file in the pull request for a more detailed description of the problem.

In practical terms, if you use tcpdump before 4.99.0 (for example, 4.9.3), you should either upgrade to at least 4.99.0, or backport the fixing commit to the old version. I recommend upgrading to 4.99.1.

ret2libc commented 2 years ago

It seems strange to now re-make valid a CVE that was rejected long time ago. I fear that distributions and people in general may not notice this issue, as it was already considered by security teams around the world long time ago and it was probably dismissed.

Moreover, I am not sure it really is a CVE-worthy issue. From the link, the description: "The command-line argument parser in tcpdump before 4.99.0 has a buffer overflow in tcpdump.c:read_infile(). To trigger this vulnerability the attacker needs to create a 4GB file on the local filesystem and to specify the file name as the value of the -F command-line argument of tcpdump."

Although this is probably a bug, it does not seem a very valid attack scenario as the attacker needs to be local and he needs to trick a victim user into using a file owned by the attacker for the value of -F option. I would consider the filter file (-F) very similar to a configuration file in the case of tcpdump. You should probably check your filter files before using them.

infrastation commented 2 years ago

Thank you for providing an opinion. The scope of this issue is to clarify what the problem was and what the solution is. To that end, the CVE has been reinstated.

infrastation commented 2 years ago

For those unable to make the recommended upgrade from tcpdump 4.9.3 to 4.99.x, commit the-tcpdump-group/tcpdump@8ab211a backports the fix.

infrastation commented 2 years ago

Alright, with these changes made and a few notifications sent around the case looks fully resolved, thus closing. Thanks to everyone who participated at one or another time.