Tag: Pete Batard

Rufus: 2 unspecified vulnerabilities hinted-at

~ hucktech ~ Leave a comment

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!

https://rufus.ie/
https://pete.akeo.ie/
https://skanthak.homepage.t-online.de/home.html
https://github.com/pbatard/rufus
http://www.openwall.com/lists/oss-security/2018/05/31/1

Pete Batard adds ARM support for VS2017 to Tianocore

~ hucktech ~ Leave a comment

Pete Batard  is adding Visual Studio for ARM support to the Tianocore UEFI dev toolchain:

This is a v2 of the previous patch, that takes into account the alignment of suppressed level 4 warnings between IA32, X64 and ARM, and that also removes compiler options that weren’t actually needed. The following series adds ARM compilation support for the VS2017 toolchain. With these patches, VS2017 toolchain users should be able to compile regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, ARM support does not require a specific update of Visual Studio 2017, as the ARM toolchain has been available from the very first release. We tested compiling and running the full UEFI Shell with this series, as well as a small set of applications and drivers, and found no issues. With an additional patch [1], it is also possible to use this proposal to compile a complete QEMU ARM firmware. As the patch shows, the changes that need to be applied to the EDK2 sources to achieve this are actually very minimal. However, the generated firmware does not currently boot, possibly because of the following warnings being generated by the MS compiler[…[]At this stage, since the goal of this series is to allow users to compile regular ARM UEFI applications using the VS2017 toolchain, I have non plans to spend more time on the QEMU firmware issues, especially as I suspect that reducing the firmware size back to 2 MB may not be achievable without Microsoft altering their compiler. I am however hopeful that ARM specialists can take this matter over eventually…

[1] https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a90604813f037b13

More info:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://lists.01.org/mailman/listinfo/edk2-devel
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/18614308-add-arm-support-back
https://blogs.msdn.microsoft.com/vcblog/2017/10/23/arm-gcc-cross-compilation-in-visual-studio/
https://github.com/microsoft/vslinux/issues
https://github.com/Microsoft/VSLinux/issues/110

See-also:
http://shadetail.com/blog/using-visual-studio-code-for-arm-development-introduction/

Note that Pete is not from the Microsoft Visual Studio team, he’s just doing their work for them… I hope the VS team gives Pete a complementary subscription to their commercial product! [Strange, I don’t think I’ve ever seen Microsoft add suppport for their own tools to Tianocore, it is always an external vendor that does Microsoft’s work…]

 

Rufus: insecure online behavior

~ hucktech ~ Leave a comment

[[update: see: https://github.com/pbatard/rufus/commit/c3c39f7f8a11f612c4ebf7affce25ec6928eb1cb ]]

 

 

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 https://rufus.akeo.ie/ 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.

https://github.com/pbatard/rufus

https://rufus.akeo.ie/

http://pete.akeo.ie/

EBC Debugger added to EDK2

~ hucktech ~ Leave a comment

Pete Batard has added EBC Debugger support to the EDK2 project! As I understand it, there was EBC Debugger support in the original EDK project, but it was not carried forward into the EDK2 project, so this is great news! It sounds like this initial patch will need to go through an iteration or two, so hold off until the dust settles…

“The EBC Debugger, which was present in Tianocore, is an invaluable tool for EBC development.  This patch adds it back into the EDK2, allowing, for instance, the compilation of an AARCH64 EBC debugger. […]”

EBC is a bytecode and VM that is widely used, yet barely understood by most, including security researchers.  While EBC was initially an Intel-centric technology, only supporting their Itaniaum, x86, and x64 processors, and only available from their commercial-only Intel C Compiler, these days ARM is also targetting EBC support.  I’m unclear about ARM’s EBC compiler options, perhaps only via their commecial-only compiler? I hope someone gets EBC support into an open source C compiler codebase, like clang or GCC.

More information:
https://github.com/pbatard/EbcDebugger/commit/906e87ed6ceab1c361ba6f681bef48179baf549e
https://github.com/pbatard/edk2/tree/EBCDebugger
http://www.uefi.org/node/550
https://github.com/tianocore/edk/tree/master/Sample/Universal/Ebc/Dxe
https://sourceforge.net/projects/efidevkit/files/Documents/EBC%20Debugger%20User%20Manual.pdf/download
https://lists.01.org/mailman/listinfo/edk2-devel

UEFI-NTFS updated

~ hucktech ~ Leave a comment

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 http://efi.akeo.ie) 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.

https://github.com/pbatard/uefi-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.

http://pete.akeo.ie/
http://efi.akeo.ie/
http://akeo.ie

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.