Why the parseYear is considered security vulnerability?

[phadej]

https://haskell.github.io/security-advisories/advisory/HSEC-2026-0007.html

The year parser loops over digit characters with no upper bound constraint. The accumulated digits are then passed to textToInteger, which converts the arbitrarily long decimal string into a Haskell Integer (an arbitrary-precision bignum). Because this conversion is super-linear in the number of digits, an attacker can send a JSON date string with millions of digits in the year position (e.g., {"date": "999...999-01-01T00:00:00Z"}). A relatively small payload (~1MB) can cause seconds of CPU time and hundreds of megabytes of memory consumption, creating a practical asymmetric DoS vector.

But the same is true for number literals in JSON file.

Take files with repeated digit 1, and a program which reads it and e.g. computes a logarithm of it (something quick to do)
The million digit input takes 29MB of total memory in use and roughly 0.14 seconds mutator time on my machine (see below).
The literal parsing code uses byteStringToInteger (

aeson/src/Data/Aeson/Decoding/ByteString.hs

Line 214 in 682162c

int = byteStringToInteger (BS.Unsafe.unsafeTake n bs0)

) which is essentially the same as textToInteger

Why years are somehow special, though the superlinear (but sub quadratic!) behavior is very much inherent to aeson.

module Main (main) where

import System.Environment (getArgs)
import qualified Data.ByteString as BS
import Data.Aeson (throwDecodeStrict)
import Math.NumberTheory.Logarithms (integerLog10)

main :: IO ()
main = do
    filename : _ <- getArgs
    print filename

    contents <- BS.readFile filename
    n <- throwDecodeStrict contents

    print $! integerLog10 n

% ls -lh
total 11M
-rw-rw-r-- 1 phadej phadej  237 Sep 14 21:36 aeson-literal.cabal
-rw-rw-r-- 1 phadej phadej 9.6M Sep 14 21:37 data-10000000.json
-rw-rw-r-- 1 phadej phadej 977K Sep 14 21:37 data-1000000.json
-rw-rw-r-- 1 phadej phadej  98K Sep 14 21:37 data-100000.json
-rw-rw-r-- 1 phadej phadej 9.8K Sep 14 21:37 data-10000.json
-rw-rw-r-- 1 phadej phadej 1000 Sep 14 21:37 data-1000.json
drwxrwxr-x 6 phadej phadej 4.0K Sep 14 21:30 dist-newstyle
-rw-rw-r-- 1 phadej phadej  359 Sep 14 21:37 generate.hs
-rw-rw-r-- 1 phadej phadej  365 Sep 14 21:35 run.hs

 % cabal run run -- data-1000.json +RTS -s 
"data-1000.json"
999
         153,072 bytes allocated in the heap
           3,832 bytes copied during GC
          53,096 bytes maximum residency (1 sample(s))
          28,824 bytes maximum slop
               6 MiB total memory in use (0 MB lost due to fragmentation)

% cabal run run -- data-10000.json +RTS -s
"data-10000.json"
9999
         783,320 bytes allocated in the heap
           3,832 bytes copied during GC
          53,096 bytes maximum residency (1 sample(s))
          28,824 bytes maximum slop
               6 MiB total memory in use (0 MB lost due to fragmentation)

% cabal run run -- data-100000.json +RTS -s
"data-100000.json"
99999
       6,728,624 bytes allocated in the heap
         150,040 bytes copied during GC
          44,328 bytes maximum residency (1 sample(s))
          29,400 bytes maximum slop
               8 MiB total memory in use (0 MB lost due to fragmentation)

% cabal run run -- data-1000000.json +RTS -s
"data-1000000.json"
999999
      71,560,416 bytes allocated in the heap
      26,950,472 bytes copied during GC
       9,201,496 bytes maximum residency (2 sample(s))
         194,728 bytes maximum slop
              29 MiB total memory in use (3 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0        13 colls,     0 par    0.021s   0.021s     0.0016s    0.0042s
  Gen  1         2 colls,     0 par    0.006s   0.007s     0.0033s    0.0049s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.137s  (  0.138s elapsed)
  GC      time    0.028s  (  0.028s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.165s  (  0.166s elapsed)

% cabal run run -- data-10000000.json +RTS -s
"data-10000000.json"
9999999
     771,606,872 bytes allocated in the heap
     473,703,144 bytes copied during GC
     107,164,456 bytes maximum residency (5 sample(s))
       1,399,352 bytes maximum slop
             228 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       157 colls,     0 par    0.309s   0.311s     0.0020s    0.0134s
  Gen  1         5 colls,     0 par    0.145s   0.145s     0.0290s    0.0674s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    2.005s  (  2.008s elapsed)
  GC      time    0.454s  (  0.456s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    2.459s  (  2.465s elapsed)

[phadej]

Updated an example

{-# LANGUAGE NumDecimals #-}
{-# LANGUAGE NumericUnderscores #-}
module Main (main) where

import System.Environment (getArgs)
import Data.Foldable (foldl')
import qualified Data.ByteString as BS
import Data.Aeson (throwDecodeStrict)
import Math.NumberTheory.Logarithms (integerLog10)
import Data.Integer.Conversion (byteStringToInteger)

main :: IO ()
main = do
    filename : _ <- getArgs
    print filename

    contents <- BS.readFile filename

    n <- throwDecodeStrict contents              -- aeson
    -- let n = byteStringToInteger contents         -- integer-conversion
    -- let n = naive contents                       -- naive
    -- let n = 10 ^ BS.length contents :: Integer   -- constant

    print $! integerLog10 n

naive :: BS.ByteString -> Integer
naive bs = foldl' (\acc d -> acc * 10 + toInteger d) 0 (BS.unpack bs)

Using byteStringToInteger on a million digit input takes ~0.15s, using naive approach takes 49s on my machine. That I would consider unacceptable, and that was the reason for me to create integer-conversions package. But if even integer-conversions is not considered good enough for general use, then I think the only rational consequence is to always treat (an intermediate) Integer as a security issue. I don't agree with that statement, it's too strict.

[Lysxia]

You have a point. I have to admit I mistakenly believed it was using a quadratic algorithm, whereas it is actually log-linear so the issue is much less serious. That said, from the point of view of a user, most people would expect date parsing to be uniformly instantaneous for all inputs. While auditing data types in one's application for DoS issues, many wouldn't think twice about a UTCTime field as opposed to an Integer field.

[phadej]

field as opposed to an Integer field.

My point is that it's not even need to be an Integer. Any literal will experience that behavior.

Let me augment the example with Double:

{-# LANGUAGE NumDecimals #-}
{-# LANGUAGE NumericUnderscores #-}
module Main (main) where

import System.Environment (getArgs)
import Data.Foldable (foldl')
import qualified Data.ByteString as BS
import Data.Aeson (throwDecodeStrict)
import Math.NumberTheory.Logarithms (integerLog10)
import Data.Integer.Conversion (byteStringToInteger)

main :: IO ()
main = do
    filename : _ <- getArgs
    print filename

    contents <- BS.readFile filename

    n <- throwDecodeStrict contents              -- aeson
    -- let n = byteStringToInteger contents         -- integer-conversion
    -- let n = naive contents                       -- naive
    -- let n = 10 ^ BS.length contents :: Integer   -- constant

    -- print $! integerLog10 n
    print (n :: Double) -- THE CHANGE: We are parsing into Double

naive :: BS.ByteString -> Integer
naive bs = foldl' (\acc d -> acc * 10 + toInteger d) 0 (BS.unpack bs)

---

Results

% cabal run run -- data-100000.json +RTS -s
"data-100000.json"
Infinity
       6,617,136 bytes allocated in the heap
         150,040 bytes copied during GC
          44,328 bytes maximum residency (1 sample(s))
          29,400 bytes maximum slop
               7 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0         1 colls,     0 par    0.000s   0.000s     0.0002s    0.0002s
  Gen  1         1 colls,     0 par    0.000s   0.000s     0.0001s    0.0001s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.009s  (  0.010s elapsed)
  GC      time    0.000s  (  0.000s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.010s  (  0.010s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    702,398,263 bytes per MUT second

  Productivity  93.3% of total user, 93.6% of total elapsed

% cabal run run -- data-1000000.json +RTS -s
"data-1000000.json"
Infinity
      70,381,544 bytes allocated in the heap
      26,953,816 bytes copied during GC
       9,211,376 bytes maximum residency (2 sample(s))
         201,232 bytes maximum slop
              29 MiB total memory in use (3 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0        13 colls,     0 par    0.023s   0.023s     0.0017s    0.0041s
  Gen  1         2 colls,     0 par    0.007s   0.007s     0.0035s    0.0054s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.122s  (  0.124s elapsed)
  GC      time    0.030s  (  0.030s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.152s  (  0.154s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    576,300,759 bytes per MUT second

  Productivity  80.3% of total user, 80.5% of total elapsed

% cabal run run -- data-10000000.json +RTS -s
"data-10000000.json"
Infinity
     759,564,920 bytes allocated in the heap
     473,692,696 bytes copied during GC
     107,164,456 bytes maximum residency (5 sample(s))
       1,399,352 bytes maximum slop
             228 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       155 colls,     0 par    0.261s   0.263s     0.0017s    0.0122s
  Gen  1         5 colls,     0 par    0.130s   0.131s     0.0261s    0.0598s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    1.801s  (  1.812s elapsed)
  GC      time    0.391s  (  0.393s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    2.192s  (  2.205s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    421,840,331 bytes per MUT second

  Productivity  82.1% of total user, 82.2% of total elapsed

---

So to repeat, it was not only "years" in UTCTime, it still is any numeric literal in raw JSON. Time and memory grows linear-log.

I wish that HSEC can be retro-redacted for the parseTime issue, otherwise if the bar is that low I wont care to pay attention to them.

[Lysxia]

There is a distinction to be made between "years in UTCTime" vs. numeric literals like Integer, Double and whatever else. UTCTime is used at human time scales, so one can reasonably expect UTCTime parsing to complete in constant time; if someone needs to manipulate geological time spans they would use a different type to begin with. In contrast, the intended range of Integer and Double is more application specific, so it's more reasonable to place the responsibility of managing that range on users.

[phadej]

@Lysxia you miss my point. It doesn't matter what the desired type is. As long as input has the big literal, the behaviour will be superlinear.

Parsing as bool this time:

{-# LANGUAGE NumDecimals #-}
{-# LANGUAGE NumericUnderscores #-}
module Main (main) where

import System.Environment (getArgs)
import Data.Foldable (foldl')
import qualified Data.ByteString as BS
import Data.Aeson (throwDecodeStrict)
import Math.NumberTheory.Logarithms (integerLog10)
import Data.Integer.Conversion (byteStringToInteger)

main :: IO ()
main = do
    filename : _ <- getArgs
    print filename

    contents <- BS.readFile filename

    n <- throwDecodeStrict contents              -- aeson
    -- let n = byteStringToInteger contents         -- integer-conversion
    -- let n = naive contents                       -- naive
    -- let n = 10 ^ BS.length contents :: Integer   -- constant

    -- print $! integerLog10 n
    print (n :: Bool)

naive :: BS.ByteString -> Integer
naive bs = foldl' (\acc d -> acc * 10 + toInteger d) 0 (BS.unpack bs)

And the run time / memory usage are still the same as for date time

% cabal run run -- data-1000000.json +RTS -s
"data-1000000.json"
run: AesonException "Error in $: expected Bool, but encountered Number"
      70,385,176 bytes allocated in the heap
      26,954,624 bytes copied during GC
       9,211,376 bytes maximum residency (2 sample(s))
         201,232 bytes maximum slop
              29 MiB total memory in use (3 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0        13 colls,     0 par    0.020s   0.020s     0.0015s    0.0034s
  Gen  1         2 colls,     0 par    0.006s   0.006s     0.0031s    0.0048s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.122s  (  0.124s elapsed)
  GC      time    0.026s  (  0.026s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    0.148s  (  0.150s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    577,242,236 bytes per MUT second

  Productivity  82.4% of total user, 82.6% of total elapsed

% cabal run run -- data-10000000.json +RTS -s
"data-10000000.json"
run: AesonException "Error in $: expected Bool, but encountered Number"
     759,568,552 bytes allocated in the heap
     473,693,584 bytes copied during GC
     107,164,456 bytes maximum residency (5 sample(s))
       1,399,352 bytes maximum slop
             228 MiB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       155 colls,     0 par    0.306s   0.309s     0.0020s    0.0130s
  Gen  1         5 colls,     0 par    0.142s   0.143s     0.0286s    0.0664s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    1.875s  (  1.889s elapsed)
  GC      time    0.448s  (  0.452s elapsed)
  EXIT    time    0.000s  (  0.000s elapsed)
  Total   time    2.323s  (  2.341s elapsed)

  %GC     time       0.0%  (0.0% elapsed)

  Alloc rate    405,107,871 bytes per MUT second

  Productivity  80.7% of total user, 80.7% of total elapsed

It DOESN'T MATTER what the type the program tries parse at. The big numeric literal in the input will exhibit this behavior. The parseYear fix does literally nothing, false sense of security.

[Lysxia]

Ah OK you're talking about the parsing to Value, which is separate from fromJSON...

[Bodigrim]

As long as input has the big literal, the behaviour will be superlinear.

Even aside of Integer, aeson exhibits $n \log n$ behaviour because of underlying Map / HashMap. Parsing { a1: 1, a2: 2, ... } will take superlinear time.

---

While I think the change is for the better (IMO type Year = Integer in time is a mistake), I would not classify it as a "practical" vulnerability.

[Lysxia]

I've opened an issue to discuss this in the security-advisories repo: haskell/security-advisories#339

[TristanCacqueray]

Thank you for the detailed analysis, text-iso8601 has been removed from the advisory.

[Lysxia]

Thanks, I'll update our changelogs to reflect that as well.