Security
The purpose of this page is to describe the various security and safety measures that are employed by Rufus, so that you can be confident that it is not trying to do something nefarious behind your back.
Because running anything as a bootloader it is such a critical part of the chain of trust in computing (because it only takes a compromised bootloader to compromise a whole computer, regardless of the security software it runs), we feel that any application that creates a bootable device must be be able to demonstrate that it beyond the speck of any doubts.
Therefore this page was written to help you understand that, while you may think that not much is going on on the security front, for an application such as Rufus, there is a lot more than meets the eyes with regards to openly ensuring that Rufus cannot do anything malicious behind your back.
The first thing we will mention, and as you are probably well aware of, is that Rufus is Open Source. This means that, if you are paranoid about running an executable which you did not create, it is in your power to compile your own version of Rufus from scratch. And furthermore, if you have concerns about what the application might be doing behind the scenes, you have the ability to study the source of every single component that ends up in Rufus, if you want proof that, just as we indicate, Rufus is not doing anything that you wouldn't want it to do.
But even better that, it is Free Software, which, as opposed to many other more restrictive Open Source licenses (such as BSD, Apache, etc.), ensures that, no matter what, you will always be able to compile and run your own version of Rufus from the published source, without any missing features or restrictions, compared the the original version produced by its author. Because Rufus is Free Software, it provides you with the freedom to compile and run the same binary as the one you get from the website, as opposed to a crippled version that may have parts missing, due to the use of a less user-friendly license. This, in turn, should give you greater trust that, because it is not possible for its developers to use loose licensing terms to "hide" any piece of the final application they don't want you to see, you can have greater assurance that what you see from the source is exactly what you get, and that, should you want to produce your own version, you will always have all the elements you need to do so.
Finally, this also means that, should Rufus development cease altogether, 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), as any developer will be able to come up and pick up the work exactly where it stopped. Baring the digital signature, anyone can continue to create a Rufus applications that are identical to the official ones, without any form of restrictions.
[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:
- 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)
- Validate the digital signature.
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:
- User launches Rufus and selected the tails ISO then clicks start
- 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)
- User accepts.
- 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
- Rufus completes the bootable drive creation, using the malicious files.
- 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.
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:
- 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).
- Ensure that pure UEFI boot is used for booting
- Write the ISO in DD mode if it's an ISOHybrid.
- 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
