Forem: Carey Evans

Embed a Windows manifest in your Rust program

Carey Evans — Sun, 21 Aug 2022 00:21:44 +0000

If you’re distributing a standalone program for Windows, you should include an XML application manifest, but Cargo and Rust don’t provide an easy way to do this. In this post I’ll show you how you can do this yourself.

I’m using the manifest below, which unlocks compatibility with Windows versions 7 to 11, so that Windows doesn’t lie to your program that it’s running on Vista; sets the code page to UTF-8 so that you can pass Rust strings directly to API’s like MessageBoxA; and enables long path names if you configure them in the registry, letting your current directory be very long.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
        </application>
    </compatibility>
    <asmv3:application>
        <asmv3:windowsSettings>
            <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
            <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    <asmv3:trustInfo>
        <asmv3:security>
            <asmv3:requestedPrivileges>
                <asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </asmv3:requestedPrivileges>
        </asmv3:security>
    </asmv3:trustInfo>
</assembly>

The Visual Studio Build Tools way

If you only ever compile programs for Windows, on Windows, using the Visual Studio Build Tools, you can use a build script to add your Windows manifest by passing a couple of extra arguments to LINK.EXE:

use std::{env, path::Path};

fn main() {
    if env::var("TARGET").expect("target").ends_with("windows-msvc") {
        let manifest = Path::new("hello.exe.manifest").canonicalize().unwrap();
        println!("cargo:rustc-link-arg-bins=/MANIFEST:EMBED");
        println!("cargo:rustc-link-arg-bins=/MANIFESTINPUT:{}", manifest.display());
        println!("cargo:rerun-if-changed=hello.exe.manifest");
    }
    println!("cargo:rerun-if-changed=build.rs");
}

This is what rustc does in release 1.63.

The “hold my beer” way

If you are compiling or cross-compiling with the MinGW tools, you can embed the manifest resource using inline assembly:

#![windows_subsystem = "windows"]

use std::ffi::c_void;
use std::ptr::null;

#[link(name = "kernel32")]
extern "system" {
    fn GetVersion() -> u32;
}

#[link(name = "user32")]
extern "system" {
    fn MessageBoxA(hwnd: *const c_void, lpText: *const u8, lpCaption: *const u8, uType: u32) -> i32;
}

fn main() {
    let version = unsafe { GetVersion() };
    let major_version = version & 0x0f;
    let minor_version = (version & 0xf0) >> 8;
    let build = if version < 0x80000000 { version >> 16 } else { 0 };
    let message = format!(
        "It’s raining 🐈s and 🐕s.\n\nI think this is Windows {}.{} ({}).\0",
        major_version, minor_version, build
    );
    unsafe {
        MessageBoxA(null(), message.as_ptr(), "Manifest Test\0".as_ptr(), 0x40);
    }
}

#[cfg(all(windows, not(target_env = "msvc")))]
mod manifest {
    use std::arch::global_asm;

    global_asm!(
        r#".section .rsrc$01,"dw""#,
        ".p2align 2",
        "2:",
        ".zero 14",
        ".short 1",
        ".long 24",
        ".long (3f - 2b) | 0x80000000",
        "3:",
        ".zero 14",
        ".short 1",
        ".long 1",
        ".long (4f - 2b) | 0x80000000",
        "4:",
        ".zero 14",
        ".short 1",
        ".long 1033",
        ".long 5f - 2b",
        "5:",
        ".long MANIFEST@imgrel",
        ".long 1207",
        ".zero 8",
        ".p2align 2",
    );

    #[no_mangle]
    #[link_section = ".rsrc$02"]
    static mut MANIFEST: [u8; 1207] = *br#"<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
        </application>
    </compatibility>
    <asmv3:application>
        <asmv3:windowsSettings>
            <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
            <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    <asmv3:trustInfo>
        <asmv3:security>
            <asmv3:requestedPrivileges>
                <asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </asmv3:requestedPrivileges>
        </asmv3:security>
    </asmv3:trustInfo>
</assembly>"#;
}

The inline assembly goes in a COFF section named .rsrc$01, and the manifest string goes in a section named .rsrc$02. The linker combines these into a single .rsrc section in the executable, with .long MANIFEST@imgrel in the header being turned into a relocatable reference to the manifest string.

You can combine these two approaches to work with any of the msvc, gnu and gnullvm target environments.

The easy way

Self-promotion moment: I’ve written a crate called embed-manifest that will use the MSVC approach, or generate an object file containing the manifest data in a .rsrc section and link against it, without needing to know as much about what you’re doing:

use embed_manifest::{embed_manifest, new_manifest};

fn main() {
    if std::env::var_os("CARGO_CFG_WINDOWS").is_some() {
        embed_manifest(new_manifest("Contoso.Sample"))
            .expect("unable to embed manifest file");
    }
    println!("cargo:rerun-if-changed=build.rs");
}

It has no external dependencies so it won’t slow your build down much at all.

Java Map keys should always be Comparable

Carey Evans — Sat, 15 Sep 2018 02:37:32 +0000

This article is inspired by the discovery years ago that an attacker could manipulate query parameters to turn the map data structure in many web servers into a linked list, by making all the parameter names end up in the same hash bucket, which CVE-2018-0875 reminded me of. You can read about the original discovery in CERT VU#903934 and the original post in the Full Disclosure list archives, or on YouTube from 28c3.

In Java, for example, the strings "fg", "gH" and "h)" all have a hash code of 3265, so an attacker can build query strings like fgfg=0&fggH=0&fgh)=0&gHfg=0 and so on to waste the server’s time and mount an effective denial of service. It’s not that hard to defend against; I know Jetty still limits form content to 200KB and 1,000 keys, and other servers have similar limits.

Java itself implemented a defense in the String class early in the Java 7 releases, described in the Collections Framework Enhancements in Java 7. The String class gained a new hash32 method and field which used MurmurHash3 with a random seed. This is fine for strings and HashMaps, but not so good for custom keys.

A better approach was implemented in JEP 180 for Java 8. Now, if too many hash codes map to the same bucket in the map, the list of entries can be changed into a balanced binary tree, sorted first by hash code and then by each key’s compareTo method, as long as the keys are Comparable. This is obviously the case for strings (and is special-cased in HashMap), but it should also be the case for every class used as a map key, especially if the data is potentially supplied by a hostile user.

Implementing Comparable

It’s straightforward to implement equals() and hashCode() correctly for a data class, if a bit verbose:

public final class SearchKey {
    private final String site;
    private final long userId;
    private final String query;

    public SearchKey(String site, long userId, String query) {
        this.site = Objects.requireNonNull(site);
        this.userId = userId;
        this.query = Objects.requireNonNull(query);
    }

    // getters ...

    @Override
    public int hashCode() {
        return (site.hashCode() * 31 + Long.hashCode(userId)) * 31 + query.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (!(obj instanceof SearchKey)) {
            return false;
        }
        SearchKey other = (SearchKey) obj;
        return userId == other.userId && site.equals(other.site) && query.equals(other.query);
    }
}

(I use 31 as the multiplier in the hash code because it’s prime, and x * 31 can be optimised to (x << 5) - x to be much faster on some platforms.)

As above, the same hash code can be generated for different values, like new SearchKey("fg", 12345, "fg"), new SearchKey("fg", 12345, "gH") and new SearchKey("gH", 12345, "fg"), which all hash to 3,523,625. If we used these as keys in a map-based cache, an attacker could mount a denial-of-service attack by making many queries to our service that use the same hash.

The compareTo method can be implemented by tediously comparing fields one by one:

public final class SearchKey implements Comparable<SearchKey> {
    // ...

    @Override
    public int compareTo(SearchKey o) {
        int c = site.compareTo(o.site);
        if (c != 0) {
            return c;
        }
        c = Long.compare(userId, o.userId);
        if (c != 0) {
            return c;
        }
        return query.compareTo(o.query);
    }
}

But from Java 8, it can be implemented more concisely:

public final class SearchKey implements Comparable<SearchKey> {
    private static final Comparator<SearchKey> COMPARATOR =
        Comparator.comparing(SearchKey::getSite)
            .thenComparingLong(SearchKey::getUserId)
            .thenComparing(SearchKey::getQuery);

    // ...

    @Override
    public int compareTo(SearchKey o) {
        return COMPARATOR.compare(this, o);
    }