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 definitely in your power to compile your own version of Rufus from scratch, instead of using the executable that was provided by a third party. Furthermore, if you have concerns about what the application might be doing behind the scenes, you do have the ability to study the source of every single component that ends up in Rufus, if proof is needed 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, as ensured by its GPLv3 license, which means that, as opposed to 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 any features or without any restrictions, and end up with a version that performs in the exact same manner as the one published by its author. Like all Free Software, Rufus 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, such as the ones that assert that developers should have greater "freedom" than users, including the the "freedom" to deny access to some of the feature-set from the official binary (be it by withholding some of the source, or by not giving you the ability to run your own modified version on the same set of devices as the original). 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, what you see from the source is exactly what you get if the official binary, and that you will always be in a position to compare the binary you produce on your own against the official one, to confirm that there wasn't anything added, for which you don't have the full details.
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, any new binaries being published in this fashion will be the same as if they were published by the original developer, without any form of restrictions.
While most of the development and testing of Rufus is accomplishing through the use of Microsoft Visual Studio, which is a closed source Integrated Development Environment (IDE), because of its convenience, all of the Rufus executables we publish are produced using MinGW/gcc, which are Free Software toolchains. This means that both Rufus, as well as the components that it embeds are produced using tools that can be verified for integrity.
The only exception to this, at this stage, are the UEFI:NTFS and NTFS EFI driver components, which, while being Free Source themselves, see their binaries generated through Visual Studio Community Edition, due to size constraints (sadly the gcc produced binaries are a lot larger than the Visual Studio one, and we want to keep the size of Rufus small). However, we have little 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 also using gcc to produce the EFI binaries.
Rufus uses git as its Version Control System. While this makes it convenient for anybody to access and verify the source (through the github project) it also makes it next to impossible for a malicious developer to try to insert a nefarious code change, as, through its use of hashes, git has an inherent built in security mechanism that prevents anyone from replacing old code without being noticed.
This means that, even if the main Rufus developer's machine gets hacked, it still wouldn't be possible from someone to add something malicious to the existing code, without being immediately detected.
When it comes to ensuring that the application code it up to the highest security standards, Rufus also makes uses of Coverity as well as the Visual Studio static analysis tool to help identify security related issues. You can find the latest Coverity report for the project here. While it needs to be pointed out that, due to its single-user nature, identifying things such as buffer overflows is not as critical in Rufus as it is for a web application (since it's not potentially going to allow a malicious remote user to compromise a server or access other people's data), Rufus still does take the safety of user data seriously, and we are committed to identifying and fixing any valid bug reported by the various analysis tools we have at our disposal.
As part of development, we also try to keep up to date with new threats that might be relevant for Rufus, by keeping alert to Windows applications vulnerability reports.
For instance, when it was recently exposed that there could exist a vulnerability with 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, we took the steps of adding explicit code in Rufus to alleviate that risk. We will of course continue to do something similar for 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 replace a download executable with a malicious version 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 on the website as these Hashes are already part of the signature and are automatically verified bu Windows every time the application launches.
Because Rufus does have an auto-update feature, which may download and run a new version, one thing that also needs to be considered, especially when the application that is about to launch a new version already runs elevated, is that you should not just blindly run an executable you just downloaded. As such, to prevent the possibility of someone having compromised the download server providing users with malicious downloads, whenever a new update is being downloaded, Rufus does 2 things before allowing it to run:
- Validate that the download has a digital signature and that it is valid
- Check that the name for the digital signature is one that we expect (since it would be very difficult for someone to fake our identity for digital signatures, without being detected by the certification authority).
You may remember that, the first time you launched Rufus on a computer, the first thing you saw was a dialog asking you whether you wanted to enable the check for update. And if you clicked the "More Information" button on that dialog, you would see a paragraph detailing the small amount of data that may get collected when update checks are enabled (which while exceedingly minimal, is still being disclosed).
This is being done because we believe that applications must also be 100% transparent about nay data they collect, if they are collecting data, and furthermore, that they should always be opt-in when it comes to data collection, no matter how small that collection is, whilst giving users an option to opt-out from it altogether. Therefore this is what Rufus does.
The only small exception you may see to this rule (because we were asked to do so) is in case you downloaded the file labelled rufus.exe, instead of one of the regular rufus-#.#.exe and is detailed in the FAQ.
At this stage we also feel that, because we mentioned the loaded word of "data collection", we have to stress out that the data we "collect" is really the minimal data we need for provide an update (current version of Rufus, IP address — which is collected automatically by the web server, 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. Mostly, we use the data to find trends in Windows OS usage, usage uptake for the new versions of Rufus, and which countries seem to be using Rufus the most. That's really about it.
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
