unblob icon indicating copy to clipboard operation
unblob copied to clipboard

Infinite loop during extraction

Open AndrewFasano opened this issue 1 year ago • 5 comments

Unblob can get stuck in an infinite loop extracting and recursing into the same file. Observed extracting https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC68R/GPL_RT_AC68R_300438520633.zip with the current head of main 727c385b3de669c3e2e32acc7177b0f07bd31c39.

This filesystem seems to include some sort of "bad directory" test within itself which is breaking unblob at:

GPL_RT_AC68R_300438520633.zip_extract/GPL_RT-AC68U_3.0.0.4.385.20633-g593a8ef.tgz_extract/GPL_RT-AC68U_3.0.0.4.385.20633-g593a8ef.tar_extract/asuswrt/release/src/router/e2fsprogs/tests/f_baddir

In that directory unblob just keeps repeatedly extracting the same file forever leading to paths like:

./image.gz_extract/image_extract/0-102400.extfs_extract/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/test/root/

AndrewFasano avatar Feb 18 '24 15:02 AndrewFasano

It's a bug in debugfs, probably similar to https://github.com/tytso/e2fsprogs/pull/149

qkaiser avatar Feb 19 '24 08:02 qkaiser

More specifically, the filesystem should either be ignored or fixed prior to running debugfs. File was checked in e2fsprogs at https://github.com/tytso/e2fsprogs/commit/19c78dc07fce2d6f39b5e541562afc3ca1ea38ff

qkaiser avatar Feb 19 '24 08:02 qkaiser

Be extremely cautious with e2fsprogs test files by the way, endless loops and endless directory creations by debugfs can lead to all sorts of problems on Linux systems.

qkaiser avatar Feb 19 '24 10:02 qkaiser

Thanks for the info! Is this something that should change in unblob or should I be doing something different when running unblob (or parsing the resulting file system?). Thanks!

AndrewFasano avatar Feb 19 '24 17:02 AndrewFasano

It should be handled by unblob but I don’t know know how exactly yet.

We could fix the filesystem first using fsck, but that would require running two separate commands. This would also raise the question of unblob actively modifying source files during extraction, which I don’t really like. Same thinking applies to a fix where we would get debugfs to fix the filesystem before operating on it.

Another idea would be to look at the filesystem UUID. Test samples from e2fsprogs don’t have a UUID set, while most filesystems in the wild have one.

We could definitely add some parsing/filtering to the extfs handler, making it smarter so it does not process these malformed files. It’s really close to a zip bomb really, I explored some ideas in the dedicated ticket, might revisit them. Idea is to monitor what’s being created by extraction processes and nuke them if they go haywire. This is something that can be added on top, we need to fix the root cause first tho.

qkaiser avatar Feb 19 '24 18:02 qkaiser