You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi and thank you for the notice. You don't really need a prepared sample to test this issue. The problem is that unarr extracts the paths as they are recorded in the archives, so if somebody crafts an archive containing a path which leads to directory traversal and you pass this on to the filesystem, bad things can happen.
The fix for this is pretty straightforward. You need to check if the paths are valid before you write to them. If they are not, you either need to sanitize them or you mark the file to as corrupt (the path is, after all, non-spec and the archive was probably handcrafted as an attack) and you refuse to extract them.
I probably should also do something on my side to prevent such issues from ocuring, but this needs a bit of research and consideration so I don't screw things up.
I maintain Golang bindings for unarr at https://github.com/gen2brain/go-unarr and there is this issue reported with tar archives gen2brain/go-unarr#21, along with this CVE GHSA-v9j4-cp63-qv62. Unfortunately, I don't have a sample of such an archive or a method to create such an archive. I see there are such samples at https://github.com/jwilk/traversal-archives but not sure if these can be used to reproduce the issue.
The text was updated successfully, but these errors were encountered: