Rufus: 2 unspecified vulnerabilities hinted-at

Stefan Kanthak has submitted a bug against Pete Batard’s Rufus, a Win32 GDI tool that helps create USB thumbdrives. Rufus is — these days — somewhat of a rarity, an open source tool that is a native Win32 GDI GUI C application. These days, most open source GUI tools are Qt or GTK. Even Microsoft has basically given up on Win32. Old School Windows tool. 🙂

I wish Stefan was less of an <EXPLETIVE> in how he reported it.

Pete has been writing EFI-centric Free Software for a long time, not many people can write UEFI file system drivers and Win32 GDI GUI applications. Thanks for creating all these tools for people, Pete!

Rufus: insecure online behavior

[[update: see: ]]



Vulnerability Note VU#403768
Akeo Consulting Rufus fails to update itself securely

Akeo Consulting Rufus fails to securely check for and retrieve updates, which an allow an authenticated attacker to execute arbitrary code on a vulnerable system. Akeo Consulting Rufus 2.16 retrieves updates over HTTP. While Rufus does attempt to perform some basic signature checking of downloaded updates, it does not ensure that the update was signed by a trusted certificate authority (CA). This lack of CA checking allows the use of a self-signed certificate. Because of these two weaknesses, an attacker can subvert the update process to achieve arbitrary code execution. An attacker on the same network as, or who can otherwise affect network traffic from, a Rufus user can cause the Rufus update process to execute arbitrary code. The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:
* Don’t use built-in update capabilities
* Because Rufus does not include the ability to securely install updates, any Rufus updates should be obtained from directly, using your web browser.
* Avoid untrusted networks
* Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.

Booting Windows from USB drive

Here’s a MSDN blog entry on how to boot Windows via a thumbdrive. It is basically an introduction to Rufus…

Installing Windows with Secure Boot from USB drive
July 18, 2017
by Anders Lybecker

Once and a while I reinstall my machine. It feels nice with a clean slate as I tend to install all kinds of applications that pollutes my machine. A newly installed machine just runs better somehow. My machine needs to be secure, so Secure Boot and encrypted drive via BitLocker is a must. It limits the risk of someone messing with my machine and stealing my data. Here is how…[…]

BTW, these days it is pretty rare to see a modern open source GUI tool that is written to use the native Windows Win32 GUI (GDI). These days, most GUIs are written using friendlier GUI frameworks/languages. Rufus is an ‘old school’ Windows tool, no drag-and-drop IDE-generated GUI code… 🙂


UEFI:NTFS is a generic bootloader, that is designed to allow boot from an NTFS partition, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently. In other words, UEFI:NTFS is designed to remove the restriction, which most UEFI systems have, of only providing boot support from a FAT32 partition, and enable the ability to also boot from NTFS partitions. This can be used, for instance, to UEFI-boot a Windows NTFS installation media, containing an install.wim that is larger than 4 GB (something FAT32 cannot support) or to allow dual BIOS + UEFI boot of ‘Windows To Go’ drives. […] Secure Boot must be disabled for UEFI:NTFS to work.[…]


UEFI-NTFS updated

Pete Batard of Akeo Consulting has updated UEFI:NTFS boot loader:

UEFI:NTFS – Boot NTFS partitions from UEFI

This generic bootloader, which is primarily intended for use with Rufus, is meant to allow seamless booting from an EFI bootloader, that resides on an NTFS partitions. In other words, UEFI:NTFS is designed to remove the UEFI restriction of being able to natively boot from FAT32 only, and allow NTFS boot without the need for any user intervention. This can be used, for instance, for booting an USB Windows NTFS installation media, in EFI mode, allowing support for files that are larger than 4GB (something a native EFI FAT32 partition cannot support), or allow indiscriminate EFI or BIOS boot of Windows To Go drives. The way this works, in conjuction with Rufus, is as follows:

* Rufus creates 2 partitions on the target USB disk (these can be MBR or GPT partitions). The first one is an NTFS partition occupying almost all the drive, that contains the Windows files (for Windows To Go, or for regular installation), and the second is a very small FAT partition, located at the very end, that contains an NTFS EFI driver (see as well as the UEFI:NTFS bootloader.
* When the USB drive boots in EFI mode, the first NTFS partition gets ignored by the EFI firmware and the UEFI:NTFS bootloader from the bootable FAT partition is executed.
* UEFI:NTFS then loads the relevant NTFS EFI driver, locates the existing NTFS partition on the same media, and executes the /efi/boot/bootx64.efi or /efi/boot/bootia32.efi that resides there. This achieves the exact same outcome as if the EFI firmware had native NTFS support and could boot straight from NTFS.

Akeo Consulting is an Irish Software Development company, expertise ranging from OSS development, Embedded Systems and SoCs development, Security, Web Services technologies, Operating Systems, Reverse Engineering, e-Papertechnologies and more. Pete has a blog with UEFI- and other firmware-related posts, and other UEFI-related projects.

Off-topic rant: These kinds of hacks are needed because UEFI requires FAT32 for it’s EFI System Partition (ESP). Apple also supports HFS+ as well as FAT for their ESP. UEFI spec requires vendors only support FAT. As I understand this, it’s mainly because FAT is widely-supported, Microsoft requires it for Windows OEMs, and having more than one file system would make life a bit more complex for UEFI developers, a complexity that Apple’s UEFI developers are already dealing with.  With a little bit of interop testing, each OS could have an EFI file system that understands it’s preferred native file system format, which may enable better disk encryption, and fewer support issues with the foreign FAT file system. A problem with using any other file system for UEFI is that all vendors won’t necessarily support it, an install-time issue. I wish we had Ext4 and ZFS file system drivers for UEFI in mainstream use (inside IBV solutions, so they’re useful). Microsoft will of course require only FAT for Windows OEMs. Personally, I’d like to see the UDF file system, used by DVDs, more widely adopted as the second file system for UEFI ESP, as a FAT alternative. Most OSes already support UDF (though with some edge-case errors, which could be fixed), and it’s one of the few common file systems that support large files. If you have to deal with some large ISO/image in the UEFI Shell, you’re limited by FAT32’s small file size limits. Someone has already submitted a UDF into Tianocore. It isn’t perfect, there are probably better choices for some flash-based systems, but it could enable a FAT-free Linux/FreeBSD system.