Summary
DROID hangs indefinitely (100% CPU) during binary signature matching on a specific extended-format WebP image — potential DoS vector
Environment
Type: Bug
Priority: High (potential denial-of-service in unattended batch/pipeline use)
Affects Version/s: DROID 6.9.13 (also reproduced via nanite-core:1.5.0-111, bundled DROID 6.6 / signature file v111)
Component/s: Binary signature matching (droid-core, signature.droid6 package)
Summary of issue
When running binary signature identification against a specific WebP image, DROID enters what appears to be an unbounded loop inside its byte-sequence fragment matcher, consuming 100% CPU indefinitely rather than completing or failing.
Steps to reproduce
timeout 30 ./droid.sh -Nr image.webp
echo "exit: $?"
(image is attached to Jira)
Security / availability impact
This is a potential denial-of-service vector: any system that runs DROID against untrusted or third-party content.
Cause of bug
This image get stuck in signature 280.
Signature 280 is chaining nine repeated RightFragment searches, each hunting for another FFF3[10:EB] occurrence within a 46–1439 byte window. That's exactly the shape of bug that would blow up on high-entropy compressed data (such as VP8/webp payload): 0xFFF3-ish byte patterns can occur "by chance" fairly often in random-looking compressed bytes, and if the matcher has to try many candidate positions at each of the 9 chained fragment levels, you get a combinatorial explosion.
The following signatures all have this identical issue:
ID 266, 267, 268, 269 → 6× RightFragment, each 46–1439 (width 1393)
ID 279, 280, 281 282 → 9× RightFragment, each 46–1439 (width 1393)
ID 1733 → 9× RightFragment, each 46–1439 (width 1393)
These signatures can also be potential bombs:
ID 655 → 3 fragments, widths 4 / 65528 / 128 (one fragment spans a 64KB window!)
ID 896, 897 → 2 fragments, widths 896 / 1,023,999 (~1MB window)
ID 1046, 1047 → 2 fragments, widths 999999 / 35536
ID 1293-1296 → 2 fragments, ~999999 / ~2046-35536
ID 1297, 1298 → 2 fragments, 16383 / 512
Suggested fix
A hard cap on total search attempts for each signature. This is a simple fix without changing fundamental regexp logic.
A better idea would be early termination if detection is almost certain and run the long signatures checks as last ones.
Example image that triggers combinatorial explosion when running ID=280 (mp3) signature:
Unittest that reproduces the bug. Created by @Asger-KB
Notice currently
ffSignatureFile.setMaxBytesToScan(100);
If increased to only 200 it will freeze.
FFSignatureFileTest.java
Summary
DROID hangs indefinitely (100% CPU) during binary signature matching on a specific extended-format WebP image — potential DoS vector
Environment
Type: Bug
Priority: High (potential denial-of-service in unattended batch/pipeline use)
Affects Version/s: DROID 6.9.13 (also reproduced via nanite-core:1.5.0-111, bundled DROID 6.6 / signature file v111)
Component/s: Binary signature matching (droid-core, signature.droid6 package)
Summary of issue
When running binary signature identification against a specific WebP image, DROID enters what appears to be an unbounded loop inside its byte-sequence fragment matcher, consuming 100% CPU indefinitely rather than completing or failing.
Steps to reproduce
timeout 30 ./droid.sh -Nr image.webp
echo "exit: $?"
(image is attached to Jira)
Security / availability impact
This is a potential denial-of-service vector: any system that runs DROID against untrusted or third-party content.
Cause of bug
This image get stuck in signature 280.
Signature 280 is chaining nine repeated RightFragment searches, each hunting for another FFF3[10:EB] occurrence within a 46–1439 byte window. That's exactly the shape of bug that would blow up on high-entropy compressed data (such as VP8/webp payload): 0xFFF3-ish byte patterns can occur "by chance" fairly often in random-looking compressed bytes, and if the matcher has to try many candidate positions at each of the 9 chained fragment levels, you get a combinatorial explosion.
The following signatures all have this identical issue:
ID 266, 267, 268, 269 → 6× RightFragment, each 46–1439 (width 1393)
ID 279, 280, 281 282 → 9× RightFragment, each 46–1439 (width 1393)
ID 1733 → 9× RightFragment, each 46–1439 (width 1393)
These signatures can also be potential bombs:
ID 655 → 3 fragments, widths 4 / 65528 / 128 (one fragment spans a 64KB window!)
ID 896, 897 → 2 fragments, widths 896 / 1,023,999 (~1MB window)
ID 1046, 1047 → 2 fragments, widths 999999 / 35536
ID 1293-1296 → 2 fragments, ~999999 / ~2046-35536
ID 1297, 1298 → 2 fragments, 16383 / 512
Suggested fix
A hard cap on total search attempts for each signature. This is a simple fix without changing fundamental regexp logic.
A better idea would be early termination if detection is almost certain and run the long signatures checks as last ones.
Example image that triggers combinatorial explosion when running ID=280 (mp3) signature:
Unittest that reproduces the bug. Created by @Asger-KB
Notice currently
ffSignatureFile.setMaxBytesToScan(100);
If increased to only 200 it will freeze.
FFSignatureFileTest.java