Bug 1464141 - The _asn1_check_identifier function in GNU Libtasn1 before 4.12(including 4.12) causes a NULL pointer dereference and crash when a NULL value assigned to value member in asn1_node. It will lead to a remote denial of service attack.
The _asn1_check_identifier function in GNU Libtasn1 before 4.12(including 4.1...
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libtasn1 (Show other bugs)
7.5-Alt
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Nikos Mavrogiannopoulos
BaseOS QE Security Team
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-22 09:50 EDT by owl337
Modified: 2017-07-20 07:19 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-20 04:20:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the vulnerability is triggered by ./asn1Parser $FILE (6.55 KB, application/x-rar)
2017-06-22 09:50 EDT, owl337
no flags Details

  None (edit)
Description owl337 2017-06-22 09:50:04 EDT
Created attachment 1290728 [details]
the vulnerability is triggered by ./asn1Parser $FILE

Description of problem:

The _asn1_check_identifier function in GNU Libtasn1 before 4.12(including 4.12) cause a NULL pointer dereference and crash when a NULL value assigned to value member in asn1_node. It will lead to a remote denial of service attack.

Version-Release number of selected component (if applicable):

from 2.0 to 4.12, 37 versions in total 


How reproducible:

./asn1Parser  POC

Steps to Reproduce:

$ gdb ./install/bin/asn1Parser
(gdb) set args POC
(gdb) r
…
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106	../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00007ffff7bd0b9b in _asn1_str_cat (dest=0x7fffffffe250 "PKIX1Implicit88.", dest_tot_size=130, src=0x0) at gstr.c:34
#2  0x00007ffff7bd1c2d in _asn1_check_identifier (node=0x628c50) at parser_aux.c:972
#3  0x00007ffff7bcb3e7 in asn1_parser2array (
    inputFileName=inputFileName@entry=0x604010 "/home/company/real/POC", 
    outputFileName=outputFileName@entry=0x0, vectorName=vectorName@entry=0x0, error_desc=error_desc@entry=0x7fffffffe380 "o\a@") at ASN1.y:780
#4  0x0000000000400fbb in main (argc=<optimized out>, argv=0x7fffffffe528) at asn1Parser.c:166

Actual results:

denial of service

Expected results:

denial of service

Additional info:

This vulnerability is detected by team OWL337, with our custom fuzzer collAFL. Please contact ganshuitao@gmail.com  and chaoz@tsinghua.edu.cn if you need more info about the team, the tool or the vulnerability
Comment 2 Nikos Mavrogiannopoulos 2017-06-22 10:22:29 EDT
Hi,
 Thank you for reporting that. I'd recommend to provide more information when reporting vulnerabilities. What you provide above is insufficient, e.g., how can you exploit the issue you report?

To the specifics, there are two calls to _asn1_check_identifier(), one from ASN1.y which is used for the parsing of developer-provided file and structure.c in asn1_array2tree() where the developer-provided file is converted to an array. Neither of these uses can lead to a vulnerability.
Comment 4 owl337 2017-06-23 00:21:07 EDT
(In reply to Nikos Mavrogiannopoulos from comment #2)
> Hi,
>  Thank you for reporting that. I'd recommend to provide more information
> when reporting vulnerabilities. What you provide above is insufficient,
> e.g., how can you exploit the issue you report?
> 
> To the specifics, there are two calls to _asn1_check_identifier(), one from
> ASN1.y which is used for the parsing of developer-provided file and
> structure.c in asn1_array2tree() where the developer-provided file is
> converted to an array. Neither of these uses can lead to a vulnerability.

Thanks for your reminding.
There were many other applications on parsing asn1 syntax used asn1_array2tree or asn1_parser2array function. For example, https://github.com/FrUh/BitPunch/blob/master/lib/src/bitpunch/asn1/asn1.c . In addtion, there should be lots of serialization-based applications need asn1 synax self-definetion that exist the risk for suffering the dos attack.
Comment 5 Nikos Mavrogiannopoulos 2017-06-26 03:18:52 EDT
I still do not see how can this be exploited.
Comment 9 Andrej Nemec 2017-07-20 04:20:41 EDT
Hi owl337,

Please report these issues to upstream libtasn1 project, if you haven't already done so.

Thanks.

Note You need to log in before you can comment on or make changes to this bug.