-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infinite loop during extraction #778
Comments
It's a bug in |
More specifically, the filesystem should either be ignored or fixed prior to running |
Be extremely cautious with e2fsprogs test files by the way, endless loops and endless directory creations by |
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! |
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.
|
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 727c385.
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:
The text was updated successfully, but these errors were encountered: