robmaz
commented
6 years ago The container executors of Hadoop 2.7.x do not sandbox the containers, so they can access the entire file system anyway, and since arbitrary programs or scripts can be executed there, they are currently limited in their destructive potential only by the lack of permissions for the cluster user. But they can overwrite both the execution folders of other containers (!) and the entire hdfs (!). The latter will be remedied soon by running them under a different uid than the hdfs (i.e., a "yarn" user, as is also recommended by the Hadoop docs). The former may be solved by the changed executors in Hadoop 3.x (but have to check). So this zip-slip thing is not really creating problems that we are not having already and need to solve anyway on the cluster side, now that we want to use the hdfs also as a reliable long-term object storage.
But thanks for pointing out such things.
Cheers Rupert
2018-06-06 9:33 GMT+02:00 Daniel Gómez-Sánchez notifications@github.com:
Assigned #90 https://github.com/robmaz/distmap/issues/90 to @robmaz https://github.com/robmaz.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/robmaz/distmap/issues/90#event-1665421948, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad_FfFAgel6WlZytKk9LrT5qyNx2KsuYks5t54WxgaJpZM4UcIeL .
magicDGS
A serious concern is the Zip-Slip vulnerability for every software un-compressing archived files. If the genome-index-archive contains files with
..paths, it could reach the root folder and the Hadoop cluster is open to attacks by malicious scripts/modifications.If we do not have a check for that kind of errors, it might be worthy to look at it.