Verify SixelDecoder against CVE-2022-24130
@dankamongmen found a good one: https://nvd.nist.gov/vuln/detail/CVE-2022-24130
From https://www.openwall.com/lists/oss-security/2022/01/30/3:
#!/bin/bash
printf "\ePq"
printf "#%hhu;2;%hhu;%hhu;%hhu" 0x41 100 100 100
printf "#%hhu!%u@" 0x41 0x7fffffff
printf "#%hhu!%u@" 0x41 0x7fffffff
printf "\e\\"
I should look to see what SixelDecoder will do with this.
Looks like:
int rep = (repeatCount == -1 ? 1 : repeatCount);
if (DEBUG) {
System.err.println("addSixel() rep " + rep + " char " +
Integer.toHexString(n) + " color " + color);
}
assert (n >= 0);
if (image == null) {
// The raster attributes was not provided.
resizeImage(WIDTH_INCREASE, HEIGHT_INCREASE);
}
if (x + rep > image.getWidth()) {
// Resize the image, give us another max(rep, WIDTH_INCREASE)
// pixels of horizontal length.
resizeImage(image.getWidth() + Math.max(rep, WIDTH_INCREASE),
image.getHeight());
}
// If nothing will be drawn, just advance x.
if (n == 0) {
x += rep;
if (x > width) {
width = x;
}
if (width > MAX_WIDTH) {
abort = true;
}
return;
}
So it will likely either crash with OOM error in resizeImage (bad), or abort with the width check right after (good).
-
Verify in Jexer -
Verify other terminals -
Add to term-crash-tests
Changes to jexer:
-
clamp rep to (1, 2¹⁵-1) -
Match foot's behavior: keep the image, but truncate to max width (jexer's max is currently 3840x6480)
term-crash-tests: https://gitlab.com/klamonte/term-crash-tests . Currently limited membership, will open when it's ready.
Edited by Autumn Lamonte