Ventoy has never been a secure tool. People are making the argument that it should be, which is just nutty.
If you’re one of those people that grab random fuckin’ ISO’s from all over the internet to test em out, then no. You really shouldn’t use Ventoy. If you run official ISO from recognized sources, then realistically the risk is ever present, but minimal.
Like getting in a wreck on the way to the store to pick up milk. It’s always a possibility, but not many people would stand around and make the argument that you should stay home forever because you might get into an accident, which is basically the argument against Ventoy. It’s “we’ll, it’s a crazy useful tool, but you shouldn’t use it because something might happen.”
It’s just such a bad argument. Fact of the matter is, is that if there were a non-hacky as shit way to do what Ventoy does, it would be available right now. But it’s not… Because it’s really not.
The only way to avoid the issues that Ventoy employs is to not use ISOs and use something like netboot.xyz, which presents its own set of issues. How do you know you’re not being MITM from the iPXE environment? Like, sure. You can technically verify it, but how do you know for sure on the fly?
Like, if you sit down you can pick apart any software for being an insufferable gaping asshole of security vulnerabilities.
The problem is they use binary versions of core tools like cryptsetup in their source tree, vs compiling them at build time.
This leaves the door open to supply-chain attacks. I.E. a PR with a bad cryptsetup binary, or an attack on crypt that makes its way downstream with no way to audit. This is how huge software distributions make their way to Wikipedia in a bad way: https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor
The solution is the build those binaries at build time, which a fork is working on.
The build environment was not clean to start, which is why a contributor is working to correct that.
You could also have the build scripts that run on GitHub pull the binary releases directly from their original release locations at build time, vs a file that an individual can modify in the source tree. This isn’t as good as building from source, but it’s better than nothing.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
In February 2024, a malicious backdoor was introduced to the Linux build of the xz utility within the liblzma library in versions 5.6.0 and 5.6.1 by an account using the name “Jia Tan”.[b][4] The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution through OpenSSH on the affected Linux system. The issue has been given the Common Vulnerabilities and Exposures number CVE-2024-3094 and has been assigned a CVSS score of 10.0, the highest possible score.[5]
Binary supply-chain attacks are not “minor security issues”. There is a reason many companies will not allow admins to use Ventoy.
I like Ventoy, it’s a fantastic project. I like that the author is transparent about where they won’t be spending their time. You can like a project, and recognize it’s flaws at the same time.
A contributor building a PR to solve the build concerns is not a bad thing, it’s to be celebrated. Even a short-term solution of having the build script pull the binaries from a release and checksum them would alleviate a lot of that concern. And the Windows vs Nix item would be alleviated by the GitHub build ENV. Binary releases isn’t the problem, it’s binary in the source. This is about audits and traceability more than the build itself.
Not having a security first posture on these kinds of attacks is how the xz event happened, and I would hate to see that happen to Ventoy. I look forward to contributors helping the author out.
Binary supply-chain attacks are not “minor security issues”.
Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
Not having a security first posture on these kinds of attacks is how the xz event happened
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.
I read what sounded like an intelligent follow-up on this subject. But I’m not smart enough to verify for myself, so I still refrain from using ventoy - even though I’d love to start using it again.
It was basically “wacky code from all over the place, poor coding practices, can’t find anything bad, but methods used are sus af”
Was the Ventoy binary blob issue resolved and it’s cool again?
No. But the argument itself is so stupid to me.
Ventoy has never been a secure tool. People are making the argument that it should be, which is just nutty.
If you’re one of those people that grab random fuckin’ ISO’s from all over the internet to test em out, then no. You really shouldn’t use Ventoy. If you run official ISO from recognized sources, then realistically the risk is ever present, but minimal.
Like getting in a wreck on the way to the store to pick up milk. It’s always a possibility, but not many people would stand around and make the argument that you should stay home forever because you might get into an accident, which is basically the argument against Ventoy. It’s “we’ll, it’s a crazy useful tool, but you shouldn’t use it because something might happen.”
It’s just such a bad argument. Fact of the matter is, is that if there were a non-hacky as shit way to do what Ventoy does, it would be available right now. But it’s not… Because it’s really not.
The only way to avoid the issues that Ventoy employs is to not use ISOs and use something like netboot.xyz, which presents its own set of issues. How do you know you’re not being MITM from the iPXE environment? Like, sure. You can technically verify it, but how do you know for sure on the fly?
Like, if you sit down you can pick apart any software for being an insufferable gaping asshole of security vulnerabilities.
The problem with Ventoy isn’t the ISOs.
The problem is they use binary versions of core tools like
cryptsetupin their source tree, vs compiling them at build time.This leaves the door open to supply-chain attacks. I.E. a PR with a bad
cryptsetupbinary, or an attack on crypt that makes its way downstream with no way to audit. This is how huge software distributions make their way to Wikipedia in a bad way: https://en.m.wikipedia.org/wiki/XZ_Utils_backdoorThe solution is the build those binaries at build time, which a fork is working on.
@Kongar@lemmy.dbzer0.com
Couldn’t you just compile those dependencies yourself and use your own blobs then?
Yes, but…
The build environment was not clean to start, which is why a contributor is working to correct that.
You could also have the build scripts that run on GitHub pull the binary releases directly from their original release locations at build time, vs a file that an individual can modify in the source tree. This isn’t as good as building from source, but it’s better than nothing.
Interesting! & longpanda*
Explains y’all paranoid and keeps using those binaries? Says “sorry I do this free and that would take forever”?
*
To clarify, asking if there has ever been an official developer response/debate on this.
The advantage of Ventoy is its ability to work in any environment and handle 99% of ISOs. Compiling the binaries at build time requires a mature development environment to be able to build these utilities… Your exponentially increasing the size and complexity of the project to solve a relatively minor security issue.
Ventoy is not the only way to create a bootable drive… If you don’t trust the blobs then don’t run the software.
Forking ventoy to add the complexity of building these utilities is only going to be available for *nix base environments so Windows users are pretty much shit out of luck. Your exponentially increasing the size of the project, it’s complexity, and simultaneously significantly narrowing its usability…
I said it before and I’ll say it again it’s such a bad fucking argument. It’s not mature software. It’s a literal confluence of hacks… And if you’re not comfortable with using it then don’t use it. It really is a huge security risk. But advocating that nobody use it is such stupid fucking thing.
Advocate that people understand the risks of using it but to just run around and scream about how nobody should be using it for any reason whatsoever until the maintainer closes the security hole that makes it run is pretty stupid.
You:
Wikipedia:
Binary supply-chain attacks are not “minor security issues”. There is a reason many companies will not allow admins to use Ventoy.
I like Ventoy, it’s a fantastic project. I like that the author is transparent about where they won’t be spending their time. You can like a project, and recognize it’s flaws at the same time.
A contributor building a PR to solve the build concerns is not a bad thing, it’s to be celebrated. Even a short-term solution of having the build script pull the binaries from a release and checksum them would alleviate a lot of that concern. And the Windows vs Nix item would be alleviated by the GitHub build ENV. Binary releases isn’t the problem, it’s binary in the source. This is about audits and traceability more than the build itself.
Not having a security first posture on these kinds of attacks is how the
xzevent happened, and I would hate to see that happen to Ventoy. I look forward to contributors helping the author out.Yes they are. The binaries for Ventoy aren’t even updated from release to release. It’s not even evident how old they are. So crying about an attack that only matters if these binaries are bleeding edge is absolutely a minor issue. I don’t even understand how someone of sound mind and body could possibly believe otherwise.
No one is making the argument that security doesn’t matter. No one is pushing the idea that Ventoy is secure. I’m saying singularly and only that a supply chain attack is just about the dumbest goddamn angle possible to bitch about Ventoy because I could argue that Ventoy would be more vulnerable than it is now to a supply chain attack if the binary blobs are built and updated every time you build a bootable drive. It’s just a truly fucking insane argument that shows a lack of understanding of what a supply chain attack is. The built binaries may be vulnerable and it’s difficult to prove if they are or not, but if you update the binaries all the time they’re more (attack surface is larger) than if they’re only updated when absolutely necessary…
It’s just plain a poor argument and I’m tired of every armchair expert pretending that its not. People in high security environments aren’t using Ventoy. It’s just such a ridiculous argument.
I read what sounded like an intelligent follow-up on this subject. But I’m not smart enough to verify for myself, so I still refrain from using ventoy - even though I’d love to start using it again.
It was basically “wacky code from all over the place, poor coding practices, can’t find anything bad, but methods used are sus af”
Says one dude I read on the internet :/
That’s it.
Sounds like a Chinese geek tried to make something useful, did a lot of dirty hacks to get it going.
And couldn’t properly explain because his social skills and English weren’t great.
The blobs weren’t super suspicious, just some gpld tools, basically busybox kind of stuff.
The real problem is what he made was so fucking insanely useful and needed by everyone that the standards for software skyrocketed.
Like you make a cure for cancer and everyone starts screaming at you because one of the side effects is temporary impotence.
Such a great post.
Just have 500 thinkpads and you can avoid security issues all together! A thinkpad for every distro EZEZ