Security
The purpose of this page is to describe the various security and safety measures that are being used by Rufus, to ensure that you can run the application with confidence that it is not trying to do something nefarious behind your back.
This is especially important as any application that creates bootable devices needs to be able to be 100% trusted by its users, and Rufus and its developer do take this responsibility very seriously. And while you may think that not much is going on on the security front when it comes to Rufus, you might be surprised to see just how much consideration
As you are probably aware, Rufus is Open Source, but even better that, it is Free Software [TODO:].
This also means that, should I cease Rufus development altogether for any reason, you will never be stranded as you would be with a closed source proprietary application (or a semi-open source application that still relies on closed source components). Baring the digital signature, Anybody can simply pick up the source and continue to create a Rufus applications that are identical to the ones I produce.
[TODO:] This means that both Rufus, as well as the components that it embeds are produced using tools that can be verified.
Note that, at this stage, the only exception to this are the UEFI:NTFS and NTFS driver EFI components, which, while being produced from Free Source code, are generated using Visual Studio Community Edition, due to size constraints (sadly the gcc produced binaries are a lot larger than the Visual Studio one). However, at this stage, we have no reason to believe that, even as it is closed source, using Visual Studio Community Edition to generate EFI binaries is introducing a security risk, and of course, as soon as EFI generation from gcc gets to par with the Visual Studio one, sizewise, we'll switch to using gcc to produce the EFI binaries we embed.
Rufus uses git as its Version Control System, which, while making it convenient for anybody to access and verify the source (through github) also makes it next to impossible for a malicious developer to insert a nefarious code change, as, through its use of hashes, git has a built in security mechanism that prevents someone from, say, hacking a developer's machine and replacing an old code change in the version control system, without making every single repository that was cloned from the developer's notice the change.
This means that, even if my development machine gets hacked, it still won't be possible from someone to hide a malicious change in existing code.
Rufus uses Coverity as well as the Visual Studio static analysis tool to identify security related issues. While it needs to be pointed out that, due to it's single-user nature, identifying things such as buffer overflows is not as critical in Rufus as it is for a web application because, instead of potentially allowing a malicious user to access other users' data, the worst that's likely to happen is that the application will crash, without this having the slightest impact on the security of that user's system.
Still, Rufus does take the safety of its user's data seriously, and we are committed to identify any valid bug reported by these tools and fixing it.
As part of development, we also try to keep up to date with new threats that might be relevant for Rufus.
For instance, it was recently exposed that there could exist a vulnerability when using the default Windows mechanisms of loading of DLLs, if a user had been tricked to previously download a malicious DLL into their general download folder.
As such, we added explicit code in Rufus to mitigate that risk, and will continue to do something similar for any threats that we deem relevant.
Rufus is digitally signed using both SHA-1 and SHA-256, which makes it impossible for someone to compromise the server and put a malicious Rufus executable there without being detected.
I should also point out that this is the reason why it doesn't make any sense to provide MD5 or SHA hashes of the Rufus executables that are available on the website. The Hashes are already part of the signature, so it would be completely redundant.
One thing you may not consider when adding a check for updates, but which we do, especially when this is being carried out from an application that's being run elevated, is that, if the download server gets compromised in any way, you may may very well launch a virus or troyan, that is disguising itself as an app.
Thus, if you blindly download an run what looks like an updated version of your app, it's game over.
This is why, whenever a new update is being downloaded, Rufus does 2 things:
1. Check that the name for the digital signature is one that we expect (since it is very difficult for someone to fake an identity for a digital signature without being detected) 2. Validate the digital signature.
This, we believe, ensures that, no matter what happens on the server, users will never be tricked into running a false update, that would compromise their system.
If you remember the first time you launched Rufus on a new computer, you may recall that the first thing it did was prompt you on to whether you wanted to enable the check for update. And if you clicked the "More Information" button on that prompt, you would also have seen a paragraph about the data that can get collected when update checks are enabled (which while exceedingly minimal, is still being disclosed).
This is because we believe that applications should always be 100% transparent about the data they collect, if they are collecting data, and furthermore, should always give users an option to opt-out on data collection, no matter how small that collection is. So that's what Rufus does.
[TODO:]
At this stage we also feel that, Because we mentioned the loaded word of "user data collection", I have to stress out that the data we "collect" is really the minimal data we need for provide an update (current version of Rufus being run, IP address, OS version), and that the only use we make of this data is for private usage statistics. We don't provide this data to any third party, nor do we use it to identify individual users. Currently, it's just being used to find out trends in Windows OS usage breakdown, as well as how many people are still using older versions of Rufus, and which ones.
Our prime goal while designing Rufus is to ensure that you don't voluntary or involuntarily lose data that you didn't mean to lose. [TODO:]
[TODO:].
Currently, in some circumstances, Rufus will request a download for a GRUB or Syslinux file from our download servers. At this stage, the integrity of these downloads is not being checked (and the reason that makes an external download necessary also renders that any kind of check difficult, as it would need to apply to yet-to-be-released elements).
We identify this as a potentially major security risk, which we want our users to be aware of, as this could lead to very serious compromise of important boot files. For instance, let's consider that a user wants to create a bootable USB with the latest version of tails, and that a government agency, which we will call the ASN, is trying to compromise their bootable drive. Even as the user took all precautions to validate that the version they obtained of the tails ISO is untouched, they may still run in the following scenario while using Rufus:
1. User launches Rufus and selected the tails ISO then clicks start 2. Rufus alerts the user that it needs to download 2 Syslinux components from its server. These are low level components that are executed very early during the boot process (but only in BIOS/Legacy mode - in UEFI mode, these are not being used at all) 3. User accepts. 4. The ASN, which monitors traffic to the Rufus download server, detects the request and injects its own version of the files instead of the ones from the servers 5. Rufus completes the bootable drive creation, using the malicious files. 6. User boots tails in BIOS/Legacy mode, and the malicious contents gets executed during first stage boot, which can set up a specific vulnerability, or take action to disclose the real identify of the tails user to the ASN, when they visit a site such as wikileaks, etc.
Of course, this is a less than ideal situation, and we are still trying to devise a way to mitigate these concerns.
While we believe that it is unlikely that actual tails users can be targeted this way (creating a first stage bootloader that can do what's described above, while still looking innocuous in size, seems like a next to impossible challenge), we can offer the following advice if you are worried:
1. Disconnect from the internet when creating the flash drive. This will force Rufus to use its internal Syslinux files (which, as far as we know, should work in most cases). 2. Ensure that pure UEFI boot is used for booting 3. Write the ISO in DD mode if it's an ISOHybrid. 4. Validate that downloaded ldlinux.sys and ldlinux.bss
We don't have reproducible builds implemented yet, primarily due to time constraints. But we are considering implementing those when we have the time to look into it.
We do have plans to add a SHA-256 table for the files we download from our servers, and that we know of at the time of the release of Rufus. This should ensure that we can report to users if their download from the server was safe, in case of a pre-existing file, as well as add a caution warning for unknown ones.
Copyright © 2012-2025 Pete Batard
