From c9f4b7f9876c1fc18651c788d3545309750a36d0 Mon Sep 17 00:00:00 2001
From: atulkharerivos <108362904+atulkharerivos@users.noreply.github.com>
Date: Sun, 15 Jan 2023 00:31:21 -0800
Subject: [PATCH] Add advisory for elf_rs crate (#1450)

* Add advisory for elf_rs crate

This adds an advisory for the elf_rs crate.

* Update crates/elf_rs/RUSTSEC-0000-0000.md

Co-authored-by: pinkforest(she/her) <36498018+pinkforest@users.noreply.github.com>

Co-authored-by: pinkforest(she/her) <36498018+pinkforest@users.noreply.github.com>
---
 crates/elf_rs/RUSTSEC-0000-0000.md | 44 ++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 crates/elf_rs/RUSTSEC-0000-0000.md

diff --git a/crates/elf_rs/RUSTSEC-0000-0000.md b/crates/elf_rs/RUSTSEC-0000-0000.md
new file mode 100644
index 0000000..831a319
--- /dev/null
+++ b/crates/elf_rs/RUSTSEC-0000-0000.md
@@ -0,0 +1,44 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "elf_rs"
+date = "2022-10-31"
+url = "https://github.com/vincenthouyi/elf_rs/issues/11"
+categories = ["memory-corruption"]
+keywords = ["elf", "header"]
+
+[versions]
+patched = []
+
+[affected]
+```
+
+# ELF header parsing library doesn't check for valid offset
+
+The crate has several unsafe sections that don't perform proper pointer validation.
+
+An example can be found in the following function:
+
+```
+fn section_header_raw(&self) -> &[ET::SectionHeader] {
+    let sh_off = self.elf_header().section_header_offset() as usize;
+    let sh_num = self.elf_header().section_header_entry_num() as usize;
+    unsafe {
+        let sh_ptr = self.content().as_ptr().add(sh_off);
+        from_raw_parts(sh_ptr as *const ET::SectionHeader, sh_num)
+    }
+}
+```
+
+While this will work perfectly fine *if* the ELF header is valid, malicious or
+malformed input can contain a section header offset of an arbitrary size, meaning
+that the resultant pointer in the unsafe block can point to an artibrary address
+in the address space of the process.
+
+This can result in unpredictable behaviour, and in our fuzz testing, we discovered
+that it's trivial to cause SIGABRT (signal 6), or SEGV (signal 11).
+
+The function should either be marked as unsafe, with a note that the caller is responsible
+for providing only valid inputs, or it should ideally do the due diligence to ensure that the
+offset doesn't exceed the bounds of the header (and add additional checks as necessary).
+