Lucene search

K
exploitdbShawn the R0ckEDB-ID:24865
HistoryMar 22, 2013 - 12:00 a.m.

GnuTLS libgnutls - Double-Free Certificate List Parsing Remote Denial of Service

2013-03-2200:00:00
Shawn the R0ck
www.exploit-db.com
19

6.6 Medium

AI Score

Confidence

Low

7.5 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P

0.022 Low

EPSS

Percentile

89.2%

Sorry I forgot to write headers in previous mail.

# Exploit Title: [possible ways to exploit CVE-2012-1663( GNUTLS-3.0.13)]
# Google Dork: [if relevant]  (we will automatically add these to the GHDB)
# Date: [Mar 20, 2013]
# Exploit Author: [Shawn the R0ck]
# Vendor Homepage: [http://www.gnutls.org/]
# Software Link: [download link if available]
# Version: [<= 3.0.13]
# Tested on: [GNU/Linux]
# CVE : [CVE-2012-1663]

PoC: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/24865.tar.bz2

I'm glad to share this to you guys. The test code was attached. You
also could find them here:
https://github.com/citypw/arsenal-4-sec-testing/tree/master/libgnutls/CVE-2012-1663

CVE-2013-1663[1] is a possible remote DOS attack issue. This issue has
been fixed[2] in >=GNUTLS-3.0.14. I hacked on it for hours and figure out
a few prerequisites could make it vulnerable:

=============================
REQUIRED:

 - prior to GNUTLS 3.0.14
 - crafted certificate

=============================
Attacking SCENES

 - a client import a crafted cert file for sending req to server( CA?)

 - a "server" import a crafted cert file for sending req to other
   server( CA?)

---> With high frequency uses above manipulations

Stand on the client side, the attacker should try to construct a
crafted certificate for triggering the below function fails:

ret = gnutls_pubkey_import_x509(pcert->pubkey, crt, 0);
  if (ret < 0)
    {
      gnutls_pubkey_deinit(pcert->pubkey);
      /* pcert->pubkey should be NULL now */
      ret = gnutls_assert_val(ret);
      goto cleanup;
    }

I made up two crafted cert files( client.pem, client2.pem) seems would
trigger the double free issue in client's side.

Warning: Don't try it on your host machine because it would cost too
much memory then makes your machine very slow.

shawn@sl13:~/gnutls_compile_uses/CVE-2012-1663$ ./ex-serv-x509
processing server set to null?
Server ready. Listening to port '5556'.

shawn@sl13:~/gnutls_compile_uses/CVE-2012-1663$ ./attack.sh
................
.................
...................

Another terminal: killall client

Test platform: Slackware 13.37 + GNUTLS-3.0.13

[1] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1663

[2] Upstream fix
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=9c62f4feb2bdd6fbbb06eb0c60bfdea80d21bbb8


-- 
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn

6.6 Medium

AI Score

Confidence

Low

7.5 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P

0.022 Low

EPSS

Percentile

89.2%