profile
viewpoint
Yechan Bae Qwaz @sslab-gatech Atlanta, Georgia https://qwaz.github.io/ 2nd yeas Ph.D. student at Georgia Tech SSLab. Member of r00timentary and LeaveCat-PLUS.

PLUS-POSTECH/Owl 7

Exploit management tool for attack and defense hacking competitions

Qwaz/resume 6

:pencil: Personal History

Qwaz/ctf-env-setup 2

:game_die: CTF environment setup script for Ubuntu

Qwaz/AI2015-python3 1

2015 포카전 슬라임 땅따먹기 Python 3 Skeleton

Qwaz/blind-vote 1

:see_no_evil: 파이썬 Flask 프레임워크로 만들어진 간단한 익명투표 사이트입니다.

Qwaz/GraphAnalyzer 1

GSHS R&E project - filter and visualize time series graph data

Qwaz/GSHSmeal 1

:fork_and_knife: GSHS meal rating system

Qwaz/komodi 1

Visual programming language with static typing and translation-time check

Qwaz/nano 1

:thought_balloon: Easy to learn Python 3 neural network

JOE1994/miri 0

An interpreter for Rust's mid-level intermediate representation

startedmicrosoft/vcpkg

started time in 13 hours

issue openedrust-lang/futures-rs

MappedMutexGuard Send/Sync bound is unsound

Hello, we have noticed a soundness/memory safety issue in this crate which allows safe Rust code to trigger undefined behavior while scanning crates.io.

https://github.com/rust-lang/futures-rs/blob/7340d3d5d6fe8082a73069582b048ebaef6626b1/futures-util/src/lock/mutex.rs#L404-L405

Description

Send/Sync implementation for MappedMutexGuard only considers variance on T, while MappedMutexGuard dereferences to U. This can lead to data race in safe Rust code when a closure used in MutexGuard::map() returns U that is unrelated to T.

Demonstration

  • Crate: futures
  • Version: 0.3.6
  • OS: Ubuntu 20.04.1 LTS
  • Rust: rustc 1.47.0 (18bf6b4f0 2020-10-07)
#![forbid(unsafe_code)]

use crossbeam_utils::thread;
use futures::lock::{Mutex, MutexGuard};
use std::ops::Deref;
use std::rc::Rc;

const NUM_CLONES: usize = 1000000;

fn main() {
    let mutex = Mutex::new(true);
    let mutex_guard = futures::executor::block_on(mutex.lock());

    // T: bool, U: Rc<bool>
    // MappedMutexGuard is Send+Sync and Deref to U, due to:
    // unsafe impl<T: ?Sized + Send, U: ?Sized> Send for MappedMutexGuard<'_, T, U> {}
    // unsafe impl<T: ?Sized + Sync, U: ?Sized> Sync for MappedMutexGuard<'_, T, U> {}
    let mapped_mutex_guard = MutexGuard::map(mutex_guard, |_| Box::leak(Box::new(Rc::new(true))));

    // We demonstrate the issue by racing the non-atomic reference counter type `Rc` between two threads.
    thread::scope(|s| {
        let child = s.spawn(|_| {
            // &Rc<bool> sent to another thread
            let rc_ref = mapped_mutex_guard.deref();
            for _ in 0..NUM_CLONES {
                std::mem::forget(rc_ref.clone());
            }
        });

        // if `child.join().unwrap()` is here, the program succeeds

        let rc_ref = mapped_mutex_guard.deref();
        for _ in 0..NUM_CLONES {
            std::mem::forget(rc_ref.clone());
        }

        child.join().unwrap();

        // We made NUM_CLONES on both threads plus initial 1 reference.
        // But in reality we'll see that the strong_count varies across every run due to data race.
        assert_eq!(Rc::strong_count(rc_ref), 2 * NUM_CLONES + 1);
    })
    .unwrap();
}

Output:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1240979`,
 right: `2000001`', src/main.rs:64:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Return Code: 101

created time in 3 days

startedtiby312/dinotree_alg

started time in 3 days

push eventQwaz/ctf-env-setup

Yechan Bae

commit sha 2a5445e0e16b4888e6584b29708a1443a42d6957

Enable mouse mode in .tmux.conf

view details

push time in 6 days

issue commentRustSec/advisory-db

Support multiple URLs in the URL field

I like the name references. One question though, what would be the recommendation if there are multiple equally definitive URLs (as in RUSTSEC-2019-0009)? Put one of them in url and the other in references, leave url empty and put both of them in references, or something else?

Qwaz

comment created time in 10 days

push eventQwaz/advisory-db

Yechan Bae

commit sha 5534479d2a15704993de97ee12346ca288f1ee4a

Initial report for 0014-sized-chunks

view details

Sergey "Shnatsel" Davidoff

commit sha e7e8aa347c4f3142ae1b5f57e879676185a67c4b

Merge pull request #381 from Qwaz/0014-sized-chunks sized-chunks: Multiple soundness issues in Chunk and InlineArray

view details

github-actions[bot]

commit sha b5df32b9e6cac96febe274a2d3b5fd11dc356bf4

Assigned RUSTSEC-2020-0041 to sized-chunks

view details

Sergey "Shnatsel" Davidoff

commit sha 49dba073a8966457720ac568c68d332a53fd1717

Merge pull request #382 from RustSec/assign-ids Assigned RUSTSEC-2020-0041 to sized-chunks

view details

Alexander Kjäll

commit sha ad7cf2f303bdf665f9bd677259f7d6da8385f212

Added CVE number (#384) http://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-25576

view details

Alexander Kjäll

commit sha a14637fe6253ade76782a5ae0a721e65db68663a

added CVE number CVE-2020-25574 (#385) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25574

view details

Alexander Kjäll

commit sha e692f8f02f7e877e9f5c3995958e4b18ec719ff6

added CVE number https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25573

view details

Sergey "Shnatsel" Davidoff

commit sha 69c1f45479e2b688948cc7db89fbffda365286a5

Merge pull request #388 from alexanderkjall/patch-3 added CVE number

view details

Alexander Kjäll

commit sha 2be9a1531e2ef5db421cf8082e10954331c8153c

added CVE numbers https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25791 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25792 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25793 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25794 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25795 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25796

view details

Sergey "Shnatsel" Davidoff

commit sha d416cf5d86240dc4f44a9cade44cb3ba18b9b320

Merge pull request #389 from alexanderkjall/patch-4 added CVE numbers

view details

Ammar Askar

commit sha f324f2d97c0515f4cc673b02eb54899295c58826

Add advisory for atom crate

view details

Alexander Kjäll

commit sha 903e6532e6fc7c4beffa186680cc172a747f9c8f

added CVE numbers (#386) looks like some confusion if the CVE is about this or RUSTSEC-2020-0036, but it looks like this is the actual security hole https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25575

view details

Alexander Kjäll

commit sha 12198c57518511b4ebfd6f93f05d97e05cdad036

added CVE number (#387) https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25016

view details

Ammar Askar

commit sha 4c2d1c0d1bb3ed777b35ac53fd68fcd005675e26

Add advisory for out-of-bounds write in stack crate

view details

Ammar Askar

commit sha 0fdd4d8a5c6cd8cbe1dc381922307e8dd782e24f

Add patched version

view details

Sergey "Shnatsel" Davidoff

commit sha be9ff03e389fd125083f11182eeb257b85df94a3

Merge pull request #392 from ammaraskar/0016-stack Add advisory for out-of-bounds write in stack crate

view details

github-actions[bot]

commit sha 57fc37a584c50b693e6eb73b136e958ce8cc3b62

Assigned RUSTSEC-2020-0042 to stack

view details

Sergey "Shnatsel" Davidoff

commit sha 2f05940af69454807f6f6af4be311f0b0b1b8149

Merge pull request #393 from RustSec/assign-ids Assigned RUSTSEC-2020-0042 to stack

view details

Benjamin Kampmann

commit sha 61a2e157040781d479b5792e25299c56794ae749

adding ws-rs advisory

view details

Benjamin Kampmann

commit sha 5a25462b610637f5b8cb29e7bd2c4703586bafc7

the year is 2020

view details

push time in 10 days

issue openedRustSec/advisory-db

Support multiple URLs in the URL field

The current advisory format only allows a single entry in the URL field, but sometimes it is useful to include multiple URLs in advisories.

Examples:

  • RUSTSEC-2019-0034 was an advisory for two bugs, hyperium/http#354 and hyperium/http#355. I included the links in the description section and left the URL field empty, because it only supports a single entry.
  • RUSTSEC-2019-0035 used a changelog URL that lists PRs and issue IDs patched in that version, but it would be better to include precise issue numbers that are related to the issue in the advisory itself. For instance, rust-random/rand#781 mentioned in the changelog is not directly related to the bug.
  • RUSTSEC-2019-0009 put servo/rust-smallvec#148 in the URL section, while servo/rust-smallvec#149 is also relevant.

Is it too late to introduce this kind of breaking changes to the advisory format, or can we still do this as part of V3 migration (#414)?

created time in 10 days

startedsasa95/pomodor

started time in 10 days

PR closed Qwaz/solved-hacking-problem

Bump bl from 4.0.2 to 4.0.3 in /CCE/2020 Quals/wordpresso/prob/web dependencies

Bumps bl from 4.0.2 to 4.0.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rvagg/bl/releases">bl's releases</a>.</em></p> <blockquote> <h2>v4.0.3</h2> <p>Fix unintialized memory access</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rvagg/bl/commit/f659836cc84211cad41b73bad89c78f7f874c626"><code>f659836</code></a> Bumped v4.0.3</li> <li><a href="https://github.com/rvagg/bl/commit/7a4ae7f818a4ceba234f3d186a1ffb3f0a34ad0c"><code>7a4ae7f</code></a> Node v14</li> <li><a href="https://github.com/rvagg/bl/commit/d3e240e3b8ba4048d3c76ef5fb9dd1f8872d3190"><code>d3e240e</code></a> Fix unintialized memory access</li> <li><a href="https://github.com/rvagg/bl/commit/1c590ad49e10a158783ada7cc0662d9e0cc6cc11"><code>1c590ad</code></a> add license MIT tag to package.json (<a href="https://github-redirect.dependabot.com/rvagg/bl/issues/83">#83</a>)</li> <li>See full diff in <a href="https://github.com/rvagg/bl/compare/v4.0.2...v4.0.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

1 comment

1 changed file

dependabot[bot]

pr closed time in 10 days

pull request commentQwaz/solved-hacking-problem

Bump bl from 4.0.2 to 4.0.3 in /CCE/2020 Quals/wordpresso/prob/web

This is part of CTF challenges and is intentionally vulnerable. dependabot seems really cool, but I think I should disable it for this repository.

dependabot[bot]

comment created time in 10 days

startedGrammaTech/gtirb

started time in 12 days

startedGrammaTech/ddisasm

started time in 12 days

push eventQwaz/solved-hacking-problem

Yechan Bae

commit sha d75d6185307ff3c02107a3b7a4407113baf9116b

Participate CCE 2020 Quals

view details

push time in 12 days

push eventQwaz/solved-hacking-problem

Yechan Bae

commit sha 11614aeffbbda66e468b56a0fa1a0f35e7e34af8

Participate Google CTF 2020 Quals

view details

push time in 12 days

push eventQwaz/ctf-env-setup

Yechan Bae

commit sha a8ebdb0a32bb739f378a1b3683fd6c43725f2ac4

Update README

view details

push time in 12 days

push eventQwaz/ctf-env-setup

Yechan Bae

commit sha d1b7ac5006a36f1fbb0732b201490f91ff01d554

Fix double prompt

view details

push time in 12 days

push eventQwaz/ctf-env-setup

Yechan Bae

commit sha 05148c8ae7c12d4587955ecb0c8ed6f547c57e80

Modify default options

view details

Yechan Bae

commit sha 69093bcb3a51e62fcc81421d2aad3e5c266c367e

Tmux configuration

view details

push time in 12 days

startedrust-secure-code/projects

started time in 13 days

startedangr/rex

started time in 22 days

startedrust-lang/rustwide

started time in 22 days

startedpython-poetry/poetry

started time in 23 days

startedsdispater/tomlkit

started time in 23 days

push eventQwaz/qwaz.github.io

Yechan Bae

commit sha 9f68c79335c4519059243a60c045f6891a3ea9a6

2020 September update

view details

push time in a month

startedalexanderkjall/deb-rust-sec

started time in a month

issue closedshepmaster/snafu

Non static error type chaining

Hello, I'm currently working on a project which uses an arena allocator. This setup makes almost all values and errors have 'arena lifetime.

The problem is that every type that goes to source field should have 'static lifetime because of the requirement of the Error trait. This restriction makes it impossible to use Snafu to chain my error types via source field.

If my understanding is correct, Snafu's mechanism for attaching context to hierarchical errors does not necessarily need 'static lifetime. Is there a way to opt-out from automatic implementation of Error trait or make source() always return None, and use non static error types for error chaining?

closed time in a month

Qwaz

issue commentshepmaster/snafu

Non static error type chaining

Seems so, I was searching with keyword "static" and missed that!

Qwaz

comment created time in a month

issue openedshepmaster/snafu

Non static error type chaining

Hello, I'm currently working on a project which uses an arena allocator. This setup makes almost all values and errors have 'arena lifetime.

The problem is that every type that goes to source field should have 'static lifetime because of the requirement of the Error trait. This restriction makes it impossible to use Snafu to chain my error types via source field.

If my understanding is correct, Snafu's mechanism for attaching context to hierarchical errors does not necessarily need 'static lifetime. Is there a way to opt-out from automatic implementation of Error trait or make source() always return None, and use non static error types for error chaining?

created time in a month

issue commentrust-lang/unsafe-code-guidelines

Validity of integers and floating point

I think the complexity of corner cases that arise by allowing uninitialized values outweighs the gain. There were great comments explaining the trickiness of undefinedness propagation. Another thing that I would like to bring up is the location of unsafe keyword for uninitialized values.

  • It is safe to construct a raw pointer, but it is unsafe to dereference them.
  • It is safe to call MaybeUninit::uninit(), but it is unsafe to call MyabeUninit::assume_init().
  • It is unsafe to create uninitialized value, but it is safe to call arithmetic operations on them.

Not only the location of unsafe keyword is the opposite from other language constructs, it's also bad in terms of locality and reasoning. When handling raw pointers, programmers can check whether all invariants are fulfilled before dereferencing it However, in case of uninitialized values, the unsafe block guarantees up front that all future use of this value will not cause undefined behavior. This looks too error-prone, and allowing uninitialized value behind numeric types doesn't seem to match well with other parts of unsafe Rust design.

RalfJung

comment created time in a month

startedtree-sitter/tree-sitter

started time in a month

startedmicrosoft/onefuzz

started time in a month

startedhakimel/reveal.js

started time in a month

startedrajephon/gvsc

started time in a month

issue commentrust-lang/rust

Retrieving closure signature causes panic

I had the same problem. I solved it by calling .as_closure().sig() on ty = instance.ty(tcx, ParamEnv::reveal_all()) instead of ty = tcx.type_of(instance.def_id()). This was fine for my usage as I only needed the Unsafety part of the signature.

FabianWolff

comment created time in a month

startedwillcrichton/rustc-type-metaprogramming

started time in a month

startedAltSysrq/proptest

started time in a month

startedGaloisInc/mir-verifier

started time in a month

startedDhghomon/programming_at_40

started time in a month

startedalessandrod/snuffy

started time in a month

startedshepmaster/snafu

started time in a month

startedstarship/starship

started time in a month

issue commentsjep/array

Multiple security issues including data race, buffer overflow, and uninitialized memory drop

Yes, since Array is a simple container type, impl<T> Send for Array<T> where T: Send and impl<T> Sync for Array<T> where T: Sync would be enough (but please double check!).

Qwaz

comment created time in a month

startedproject-oak/rust-verification-tools

started time in 2 months

startedhahnlee/hwp.js

started time in 2 months

PR opened RustSec/advisory-db

sized-chunks: Multiple soundness issues in Chunk and InlineArray

Chunk:

  • Array size is not checked when constructed with unit() and pair().
  • Array size is not checked when constructed with From<InlineArray<A, T>>.
  • Clone and insert_from are not panic-safe; A panicking iterator causes memory safety issues with them.

InlineArray:

  • Generates unaligned references for types with a large alignment requirement.

Original issue report: https://github.com/bodil/sized-chunks/issues/11

+20 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0014-sized-chunks

created branch time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha 3cd0280fe78d943a51c4240d30d5339d4b24450f

Update patched version of 0013-simple-slab

view details

Sergey "Shnatsel" Davidoff

commit sha 88c518e88a9a2efcf2d3a1970c1c0dcb8e84c83b

Merge pull request #379 from Qwaz/0013-simple-slab-patched Update patched version of 0013-simple-slab

view details

push time in 2 months

issue openedbodil/sized-chunks

Multiple soundness issues in Chunk and InlineArray

Hello, we have noticed a soundness issue and/or a potential security vulnerability in this crate while performing a security scan on crates.io.

Description

Chunk:

  • Array size is not checked when constructed with unit() and pair().
  • Array size is not checked when constructed with From<InlineArray<A, T>>.
  • Clone and insert_from are not panic-safe; A panicking iterator causes memory safety issues with them.

InlineArray:

  • Generates unaligned references for types with a large alignment requirement.

Demonstration

  • Crate: sized-chunks
  • Version: 0.6.2
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.46.0 (04488afe3 2020-08-24)
  • Cargo flags: --release
#![forbid(unsafe_code)]

mod boilerplate;

use sized_chunks::{Chunk, InlineArray};
use typenum::*;

#[repr(align(256))]
struct LargeAlign(u8);

struct DropDetector(u32);

impl DropDetector {
    fn new(num: u32) -> Self {
        println!("Creating {}", num);
        DropDetector(num)
    }
}

impl Drop for DropDetector {
    fn drop(&mut self) {
        println!("Dropping {}", self.0);
    }
}

impl Clone for DropDetector {
    fn clone(&self) -> Self {
        if self.0 == 42 {
            panic!("panic on clone")
        }
        DropDetector::new(self.0)
    }
}

struct PanickingIterator {
    current: u32,
    panic_at: u32,
    len: usize,
}

impl Iterator for PanickingIterator {
    type Item = DropDetector;

    fn next(&mut self) -> Option<Self::Item> {
        let num = self.current;

        if num == self.panic_at {
            panic!("panicking index")
        }

        self.current += 1;
        Some(DropDetector::new(num))
    }

    fn size_hint(&self) -> (usize, Option<usize>) {
        (self.len, Some(self.len))
    }
}

impl ExactSizeIterator for PanickingIterator {}

fn main() {
    boilerplate::init();

    // Some of these cases will panic earlier than assert in debug build due to overflow detection,
    // but they still have the same error

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/sized_chunk/mod.rs#L153-L177
    boilerplate::test_case(
        "1. Array size is not checked when constructed with `unit()` and `pair()`.",
        || {
            let _ = Chunk::<usize, U0>::unit(123);
            let mut chunk = Chunk::<usize, U0>::pair(123, 456);

            // Moreover, we can push more elements because `is_full` is implemented as `len != capacity`
            chunk.push_back(789);

            println!("len: {}", chunk.len());
            assert!(chunk.len() <= U0::USIZE);
        },
    );

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/sized_chunk/mod.rs#L815-L829
    boilerplate::test_case(
        "2. Array size is not checked when constructed with `From<InlineArray<A, T>>`",
        || {
            let mut from = InlineArray::<u8, [u8; 256]>::new();
            from.push(1);
            from.push(2);
            from.push(3);
            from.push(4);
            from.push(5);

            let to = Chunk::<u8, U0>::from(from);
            println!("len: {}", to.len());
            assert!(to.len() <= U0::USIZE);
        },
    );

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/sized_chunk/mod.rs#L120-L134
    boilerplate::test_case("3-1. `Chunk::clone()` is not panic-safe", || {
        let mut chunk = Chunk::<DropDetector, U3>::new();
        chunk.push_back(DropDetector::new(42));
        chunk.push_back(DropDetector::new(43));

        // observe the difference between creating and dropping log
        // uninitialized memory is dropped while unwinding
        println!("=> Dropping uninitialized memory");
        let _ = chunk.clone();
    });

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/sized_chunk/mod.rs#L564-L617
    boilerplate::test_case("3-2. `Chunk::insert_from()` is not panic-safe", || {
        let mut chunk = Chunk::<DropDetector, U5>::new();
        chunk.push_back(DropDetector::new(1));
        chunk.push_back(DropDetector::new(2));
        chunk.push_back(DropDetector::new(3));

        println!("=> Double-free of `DropDetector(2)`");
        chunk.insert_from(
            1,
            PanickingIterator {
                current: 1,
                panic_at: 1,
                len: 1,
            },
        );
    });

    boilerplate::test_case("4. `InlineArray` generates unaligned references for types with a large alignment requirement.", || {
        let mut arr = InlineArray::<LargeAlign, [usize; 256]>::new();
        arr.push(LargeAlign(0));

        boilerplate::assert_aligned(arr.get(0).unwrap());
    });

    // Other issues that should be fixed but probably minor to include in the advisory:

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/sized_chunk/mod.rs#L564-L617
    // `insert_from` relies on the behavioral correctness of `ExactSizeIterator`.
    // However, `ExactSizeIterator` is a safe trait, which has the same safety guarantee with `size_hint()`.
    // Programs should not assume that they will yield a correct value in unsafe code.
    // From Rust std doc: "An incorrect implementation of `size_hint()` should not lead to memory safety violations."
    //
    // Applying `take(insert_size)` and adjusting `left` and `right` field based on the number of items that are actually moved
    // (instead of using `insert_size`) will fix the problem.

    // https://github.com/bodil/sized-chunks/blob/40aa74b824688a4d4b1e1c65a50c679abb58b41e/src/inline_array/mod.rs#L167
    // This states an actual contract, so it should be `assert!()` instead of `debug_assert!()`
    // From Rust std doc: "Replacing `assert!` with `debug_assert!` is thus only encouraged after thorough profiling, and more importantly, only in safe code!"
}

Output:

-----------------------------------------------------------------------------
| 1. Array size is not checked when constructed with `unit()` and `pair()`. |
-----------------------------------------------------------------------------
len: 334
thread 'main' panicked at 'assertion failed: chunk.len() <= U0::USIZE', src/main.rs:109:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

--------------------------------------------------------------------------------
| 2. Array size is not checked when constructed with `From<InlineArray<A, T>>` |
--------------------------------------------------------------------------------
len: 18446744052167409156
thread 'main' panicked at 'assertion failed: to.len() <= U0::USIZE', src/main.rs:126:13

-------------------------------------------
| 3-1. `Chunk::clone()` is not panic-safe |
-------------------------------------------
Creating 42
Creating 43
=> Dropping uninitialized memory
thread 'main' panicked at 'panic on clone', src/main.rs:59:13
Dropping 150495608
Dropping 32764
Dropping 42
Dropping 43

-------------------------------------------------
| 3-2. `Chunk::insert_from()` is not panic-safe |
-------------------------------------------------
Creating 1
Creating 2
Creating 3
=> Double-free of `DropDetector(2)`
thread 'main' panicked at 'panicking index', src/main.rs:78:13
Dropping 1
Dropping 2
Dropping 2

-------------------------------------------------------------------------------------------------
| 4. `InlineArray` generates unaligned references for types with a large alignment requirement. |
-------------------------------------------------------------------------------------------------
thread 'main' panicked at 'Reference is not aligned - addr: 0x7ffc08f859e8, align: 0x100', src/boilerplate.rs:46:9

Return Code: 0

created time in 2 months

issue openedRustSec/advisory-db

Link original PR number in ID-assigning PR

ID-assigning GitHub action PRs do not contain any information that can be associated with the original PR (#378 and #373 for example) at the moment. Is it possible to include the original issue ID in an ID-assigning PR?

This would help finding the original discussion from RustSec ID number for a bug and vice versa.

created time in 2 months

PR opened RustSec/advisory-db

Update patched version of 0013-simple-slab

Fixed by https://github.com/nathansizemore/simple-slab/commit/5e0524c1db836e2192e1cd818848d96937c0b587

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0013-simple-slab-patched

created branch time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha daf2b6281ad0e7f288544a63734be401c8ab4d84

Initial report for 0011-obstack

view details

Yechan Bae

commit sha d2aaa6c1b2685b89d43ae7d1024c19436f05c876

Initial report for 0013-simple-slab

view details

Sergey "Shnatsel" Davidoff

commit sha 4947069dc851a23eaf88f5367245ddb15064d5a0

Merge pull request #376 from Qwaz/0013-simple-slab simple-slab: `index()` allows out-of-bound read and `remove()` has off-by-one error

view details

github-actions[bot]

commit sha d7fd255bf0406d6bb91780017d2e1ca1c8254a74

Assigned RUSTSEC-2020-0039 to simple-slab

view details

Sergey "Shnatsel" Davidoff

commit sha f5e8a8ef29feeaafe5d92dda82cec6cf7386609f

Merge pull request #377 from RustSec/assign-ids Assigned RUSTSEC-2020-0039 to simple-slab

view details

Sergey "Shnatsel" Davidoff

commit sha 87aae01a3674c42032ed438ea54db5172cbbacd0

mark ">= 0.1.4" as fixed

view details

Sergey "Shnatsel" Davidoff

commit sha ec4382d316738d8137c47135e0a643e4b754a757

Merge pull request #373 from Qwaz/0011-obstack obstack: Obstack generates unaligned references

view details

github-actions[bot]

commit sha 60caffb2bf31366e7716fbb2b1ea7203746ad6f4

Assigned RUSTSEC-2020-0040 to obstack

view details

Sergey "Shnatsel" Davidoff

commit sha e44d93d9c69e10558a67a6b95ab68b7edbaea0d9

Merge pull request #378 from RustSec/assign-ids Assigned RUSTSEC-2020-0040 to obstack

view details

push time in 2 months

issue commentpetertodd/rust-obstack

Obstack generates unaligned references

Thank you for a quick fix :)

Qwaz

comment created time in 2 months

PR opened RustSec/advisory-db

simple-slab: `index()` allows out-of-bound read and `remove()` has off-by-one error

Slab::index() does not perform the boundary checking, which leads to out-of-bound read access. Slab::remove() copies an element from an invalid address due to off-by-one error, resulting in memory leakage and uninitialized memory drop.

Original issue report: https://github.com/nathansizemore/simple-slab/issues/2

+12 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0013-simple-slab

created branch time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha d5811c82b21ac88e0b931cd27852662308b182f4

Update 0012-ordnung

view details

Sergey "Shnatsel" Davidoff

commit sha 0cee8f8f4d0aee84c45c33c45169aeb6a4196aaf

Merge pull request #374 from Qwaz/0012-ordnung ordnung: Memory safety issues in `compact::Vec`

view details

github-actions[bot]

commit sha 75a29e606ae63414855e84f2983675c3d1bdda4d

Assigned RUSTSEC-2020-0038 to ordnung

view details

Sergey "Shnatsel" Davidoff

commit sha 95868762d326e2ea2d343d0f8ad972162191640d

Merge pull request #375 from RustSec/assign-ids Assigned RUSTSEC-2020-0038 to ordnung

view details

push time in 2 months

issue openednathansizemore/simple-slab

`index()` allows out-of-bound read and `remove()` has off-by-one error

Hello, we have noticed a soundness issue and/or a potential security vulnerability in this crate while performing a security scan on crates.io.

https://github.com/nathansizemore/simple-slab/blob/f1b18e1ed42b5477d43c837155998d566fdaf461/src/lib.rs#L160-L165

https://github.com/nathansizemore/simple-slab/blob/f1b18e1ed42b5477d43c837155998d566fdaf461/src/lib.rs#L82-L103

Description

Slab::index() does not perform the boundary checking, which leads to out-of-bound read access. Slab::remove() copies an element from an invalid address due to off-by-one error, resulting in memory leakage and uninitialized memory drop.

Demonstration

  • Crate: simple-slab
  • Version: 0.3.2
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.46.0 (04488afe3 2020-08-24)
#![forbid(unsafe_code)]

mod boilerplate;

use simple_slab::Slab;

#[derive(Debug, PartialEq)]
struct DropDetector(u32);

impl Drop for DropDetector {
    fn drop(&mut self) {
        println!("Dropping {}", self.0);
    }
}
fn main() {
    boilerplate::init();

    let mut slab = Slab::with_capacity(2);
    slab.insert(DropDetector(123));
    slab.insert(DropDetector(456));

    // 1. No boundary checking leads to OOB read in `index()`
    println!("{:?}", slab[20]);

    // 2. Memory leak / uninitialized memory access in `remove()`
    // element should be copied from `len - 1`, not `len`
    assert_eq!(slab.remove(0).0, 123);
    assert_eq!(slab[0].0, 456); // copied from uninitialized region `slab[2]`
}

Output:

DropDetector(3090534592)
Dropping 123
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `456`', src/main.rs:49:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Dropping 0

Return Code: 101

created time in 2 months

issue commentmaciejhirsz/ordnung

Memory safety issues in `compact::Vec`

In addition, creating a reference that points to an invalid value is already an undefined behavior, even if it is not dereferenced.

https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L161 https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L295-L298

I don't see any location where [T] field is directly used. Maybe a tuple (*ptr: *mut T, len: u32, cap: u32) has the same semantics and the performance while less error-prone.

Qwaz

comment created time in 2 months

push eventQwaz/advisory-db

Jakub Kądziołka

commit sha b1d3a5e73f82f96a1ee5d4a4135832c56416e2bd

Advisory for rio

view details

Yechan Bae

commit sha f81972e8c465a3a205bd58f2062d06c48258942d

Informational advisory for rust-lang-nursery/failure#336

view details

Yechan Bae

commit sha 226a6d6dad7b8dd1d5177cc41bb167dff342232e

Security advisory for SergioBenitez/Rocket#1312

view details

Yechan Bae

commit sha 7c96397ea1579cde0d701666d2c804e60f2825d9

Security advisory for AtheMathmo/rulinalg#201

view details

Yechan Bae

commit sha 8149410e8dae63bce2883f2bb53b4e5b7d73e38b

Fix toml format error

view details

Tony Arcieri

commit sha 45495b767e813e9a344e41defebcfd7b9de05115

.github: bump rustsec-admin cache key (#321) ...to match the new `rustsec-admin` v0.2.0 release: https://github.com/RustSec/rustsec-admin/pull/57

view details

Alex Gaynor

commit sha 418954a939cbf0594c09a754bbb31989a89203fd

Create github action to assign RUSTSEC ids (#311) * Create github action to assign RUSTSEC ids * Bump

view details

Alex Gaynor

commit sha 48c8653408aff55c36fbf7df369507b304d00f8e

Attempt to fix failing assign-ids task (#322)

view details

quininer

commit sha de07a7d2078d70b88d04b24ab954278a2c5b6ce7

Add tokio-rustls DoS advisory (#304)

view details

github-actions[bot]

commit sha 46c23f6c942d2567bd71c25bf693f840d4b752a1

Assign RUSTSEC IDs (#323) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Ralf Jung

commit sha 9cd619f16780d0242fccf52fd910f0f43564dad1

make memoffset advisory informational (#317)

view details

Tony Arcieri

commit sha 1dfcb1d64acee8add938a5fe0d4e4d003dde9688

.github: lint advisories after assigning ID (#324)

view details

Jeff Muizelaar

commit sha 6e2241c06b289ed483b1f18acab8c33b0e6a3322

stb_truetype crate has been deprecated; use ttf-parser instead (#307)

view details

github-actions[bot]

commit sha 07ae3fb20715edaebf4113e17dab08e62cb33396

Assign RUSTSEC IDs (#325) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Yechan Bae

commit sha 49fcc50d2b596defa5a1fc2cfaef4ebafddf46f2

Reflect PR feedback and describe what might happen

view details

Tony Arcieri

commit sha 297725a1661081e19700ba7d1af0a40a04ab1018

README.md: bump maintained quarter comment

view details

Sergey "Shnatsel" Davidoff

commit sha c05fb28d6d63a5fb974a8ff7dd6fe570285c6487

Merge pull request #293 from NieDzejkob/rio Advisory for rio

view details

github-actions[bot]

commit sha 73b40e7d53b77aa7372b711459ff9abbba4d4aa2

Assign RUSTSEC IDs (#326) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Yechan Bae

commit sha ee09393d32fc1a155819d3c51900df45172055d9

Security advisory for bqv/ozone

view details

Yechan Bae

commit sha f17f55472c93b0d85fdb5dd143b32e57afb74e01

Fix the function path and make the advisory informational

view details

push time in 2 months

push eventQwaz/advisory-db

Jakub Kądziołka

commit sha b1d3a5e73f82f96a1ee5d4a4135832c56416e2bd

Advisory for rio

view details

Yechan Bae

commit sha f81972e8c465a3a205bd58f2062d06c48258942d

Informational advisory for rust-lang-nursery/failure#336

view details

Yechan Bae

commit sha 226a6d6dad7b8dd1d5177cc41bb167dff342232e

Security advisory for SergioBenitez/Rocket#1312

view details

Yechan Bae

commit sha 7c96397ea1579cde0d701666d2c804e60f2825d9

Security advisory for AtheMathmo/rulinalg#201

view details

Yechan Bae

commit sha 8149410e8dae63bce2883f2bb53b4e5b7d73e38b

Fix toml format error

view details

Tony Arcieri

commit sha 45495b767e813e9a344e41defebcfd7b9de05115

.github: bump rustsec-admin cache key (#321) ...to match the new `rustsec-admin` v0.2.0 release: https://github.com/RustSec/rustsec-admin/pull/57

view details

Alex Gaynor

commit sha 418954a939cbf0594c09a754bbb31989a89203fd

Create github action to assign RUSTSEC ids (#311) * Create github action to assign RUSTSEC ids * Bump

view details

Alex Gaynor

commit sha 48c8653408aff55c36fbf7df369507b304d00f8e

Attempt to fix failing assign-ids task (#322)

view details

quininer

commit sha de07a7d2078d70b88d04b24ab954278a2c5b6ce7

Add tokio-rustls DoS advisory (#304)

view details

github-actions[bot]

commit sha 46c23f6c942d2567bd71c25bf693f840d4b752a1

Assign RUSTSEC IDs (#323) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Ralf Jung

commit sha 9cd619f16780d0242fccf52fd910f0f43564dad1

make memoffset advisory informational (#317)

view details

Tony Arcieri

commit sha 1dfcb1d64acee8add938a5fe0d4e4d003dde9688

.github: lint advisories after assigning ID (#324)

view details

Jeff Muizelaar

commit sha 6e2241c06b289ed483b1f18acab8c33b0e6a3322

stb_truetype crate has been deprecated; use ttf-parser instead (#307)

view details

github-actions[bot]

commit sha 07ae3fb20715edaebf4113e17dab08e62cb33396

Assign RUSTSEC IDs (#325) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Yechan Bae

commit sha 49fcc50d2b596defa5a1fc2cfaef4ebafddf46f2

Reflect PR feedback and describe what might happen

view details

Tony Arcieri

commit sha 297725a1661081e19700ba7d1af0a40a04ab1018

README.md: bump maintained quarter comment

view details

Sergey "Shnatsel" Davidoff

commit sha c05fb28d6d63a5fb974a8ff7dd6fe570285c6487

Merge pull request #293 from NieDzejkob/rio Advisory for rio

view details

github-actions[bot]

commit sha 73b40e7d53b77aa7372b711459ff9abbba4d4aa2

Assign RUSTSEC IDs (#326) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

Yechan Bae

commit sha ee09393d32fc1a155819d3c51900df45172055d9

Security advisory for bqv/ozone

view details

Yechan Bae

commit sha f17f55472c93b0d85fdb5dd143b32e57afb74e01

Fix the function path and make the advisory informational

view details

push time in 2 months

issue commentmaciejhirsz/ordnung

Memory safety issues in `compact::Vec`

Run result in 32-bit with cargo run --target i686-unknown-linux-musl --release

1. OOB is possible because MASK_HI is 0 in 32-bit build.
[TRACE] > alloc [address=0x9fb15d0, size=1, align=1]
pointer: 0x9fb15d0
len: 1
capacity: 0
Pushed 0
Pushed 1
Pushed 2
Pushed 3
len: 5
capacity: 0
3. `Vec::remove()` causes double-free when panicking.
thread 'main' panicked at 'removal index (is 123) should be < len (is 34)', src/liballoc/vec.rs:1062:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Dropping 134859000
Dropping 134859000
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 123
Dropping 456
Dropping 134859000
Dropping 134859000
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 0
Dropping 123
Dropping 456
Qwaz

comment created time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha 9ef0744de7ea36722110483a50ceb3758930890b

Update 0012-ordnung

view details

push time in 2 months

PR opened RustSec/advisory-db

ordnung: Memory safety issues in `compact::Vec`

compact::Vec contains multiple memory safety issues.

  1. It mishandles large capacity and causes out-of-bound access in 32-bit / allocator layout mismatch in 64-bi.
  2. remove() is not panic-safe and causes double-free when an index larger than the length is provided.

Original issue report: https://github.com/maciejhirsz/ordnung/issues/8

+28 -0

0 comment

2 changed files

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0012-ordnung

created branch time in 2 months

issue openedmaciejhirsz/ordnung

Memory safety issues in `compact::Vec`

Hello, we have noticed a soundness issue and/or a potential security vulnerability in this crate while performing a security scan on crates.io.

Description

compact::Vec contains multiple memory safety issues.

  1. It mishandles large capacity and causes out-of-bound access in 32-bit / allocator layout mismatch in 64-bi.
  2. remove() is not panic-safe and causes double-free when an index larger than the length is provided.

Demonstration

  • Crate: ordnung
  • Version: 0.0.1
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.46.0 (04488afe3 2020-08-24)
#![forbid(unsafe_code)]

mod boilerplate;

use ordnung::compact::Vec as CompactVec;

struct DropDetector(u32);

impl Drop for DropDetector {
    fn drop(&mut self) {
        println!("Dropping {}", self.0);
    }
}

fn main() {
    boilerplate::init();

    #[cfg(target_pointer_width = "32")]
    {
        println!("1. OOB is possible because MASK_HI is 0 in 32-bit build.");

        boilerplate::trace_alloc(move || {
            let mut vec: Vec<u8> = Vec::with_capacity(1);
            vec.push(1);

            // https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L281-L282
            // len / cap packing doesn't work in 32-bit environment and cap will be always zero.
            // Admittedly, this is not a real security threat as the code will scream and panic in the debug build.
            // However, it is still a soundness issue since it allows UB in safe Rust code.
            // This crate doesn't seem to support 32-bit, so it would be better to make it an error at the compile time.
            let mut compact_vec = CompactVec::from(vec);
            println!("pointer: {:p}", compact_vec.as_ptr());
            println!("len: {}", compact_vec.len());
            println!("capacity: {}", compact_vec.capacity());

            // https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L48
            // Allows us to push elements over the boundary because `len != cap`
            for i in 0..4 {
                compact_vec.push(i);
                println!("Pushed {}", i);
            }
            println!("len: {}", compact_vec.len());
            println!("capacity: {}", compact_vec.capacity());

            // cap is 0, so no deallocation
        });
    }

    #[cfg(target_pointer_width = "64")]
    {
        println!("2. Allocator layout mismatch in 64-bit build with large capacity.");

        boilerplate::trace_alloc(|| {
            // https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L35-L37
            // Allocation is done with capacity `(1 << 32) + 4`,
            let _ = CompactVec::<u8>::with_capacity((1 << 32) + 4);
            // https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L185-L193
            // but deallocation is done with capacity `4`.
            // This may corrupt the internal state of the allocator, which can cause the memory safety violation.
        });
    }

    {
        println!("3. `Vec::remove()` causes double-free when panicking.");

        let mut compact_vec = CompactVec::with_capacity(32);
        compact_vec.push(DropDetector(123));
        compact_vec.push(DropDetector(456));

        // https://github.com/maciejhirsz/ordnung/blob/e1f1e3bda332dae33b76ca4be00dba46265e4cbe/src/compact.rs#L139-L152
        // Panic in line 144 frees a temporary vector created in line 142,
        // and the same vector is freed again when `compact_vec` is dropped while stack unwinding.
        compact_vec.remove(123);
    }
}

Output:

2. Allocator layout mismatch in 64-bit build with large capacity.
[TRACE] > alloc [address=0x7f9b011c0010, size=4294967300, align=1]
[TRACE] > dealloc [address=0x7f9b011c0010, size=4, align=1]
3. `Vec::remove()` causes double-free when panicking.
thread 'main' panicked at 'removal index (is 123) should be < len (is 2)', src/liballoc/vec.rs:1062:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Dropping 123
Dropping 456
Dropping 0
Dropping 0

Return Code: 101

created time in 2 months

create barnchQwaz/advisory-db

branch : 0011-obstack

created branch time in 2 months

PR opened RustSec/advisory-db

obstack: Obstack generates unaligned references

Obstack generates unaligned references for types that require a large alignment.

Original issue report: https://github.com/petertodd/rust-obstack/issues/4

+13 -0

0 comment

1 changed file

pr created time in 2 months

issue openedpetertodd/rust-obstack

Obstack generates unaligned references

https://github.com/petertodd/rust-obstack/blob/e1dde0dbed709ebdea9bd1f79ec718e80c5d0bf6/src/lib.rs#L317-L337

Description

Obstack generates unaligned references for types that require a large alignment.

Demonstration

  • Crate: obstack
  • Version: 0.1.3
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.46.0 (04488afe3 2020-08-24)
  • Cargo flags: --release
#![forbid(unsafe_code)]

use obstack::Obstack;

#[repr(align(256))]
#[derive(Copy, Clone)]
struct LargeAlign(u8);

fn main() {
    // https://github.com/petertodd/rust-obstack/blob/e1dde0dbed709ebdea9bd1f79ec718e80c5d0bf6/src/lib.rs#L317-L337
    // Line 322: Incorrect padding bytes calculation. It should be `(alignment - (start_ptr % alignment)) % alignment`.
    // Line 329: Wasted memory due to `bytes_to_item()` not being applied to `padding`.

    // Due to the incorrect padding calculation, the code generates unaligned reference in release mode.
    let obstack = Obstack::new();
    let val_ref = obstack.push_copy(LargeAlign(0));

    let address = val_ref as *mut _ as usize;
    println!("{:x}", address);
    assert!(address % std::mem::align_of::<LargeAlign>() == 0);
}

Output:

55bc0c2fc520
thread 'main' panicked at 'assertion failed: address % std::mem::align_of::<LargeAlign>() == 0', src/main.rs:39:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Return Code: 101

created time in 2 months

issue commentshawnscode/crayon

Misbehaving `HandleLike` implementation can lead to memory safety violation

https://github.com/shawnscode/crayon/blob/48d4e879996e2502e0faaf36e4dbcebfca9961b0/src/utils/object_pool.rs#L75-L87

Also, storing uninitialized T to Vec<T> is an undefined behavior even if it is not accessed AFAIK.

Qwaz

comment created time in 2 months

PR opened RustSec/advisory-db

crayon: Misbehaving `HandleLike` implementation can lead to memory safety violation

Unsafe code in ObjectPool has time-of-check to time-of-use (TOCTOU) bug that can eventually lead to a memory safety violation. ObjectPool and HandlePool implicitly assumes that HandleLike trait methods are pure, i.e., they always return the same value. However, this assumption is unsound since HandleLike is a safe, public trait that allows a custom implementation.

Original issue report: https://github.com/shawnscode/crayon/issues/87

+13 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0010-crayon

created branch time in 2 months

issue openedshawnscode/crayon

Misbehaving `HandleLike` implementation can lead to memory safety violation

https://github.com/shawnscode/crayon/blob/master/src/utils/handle.rs#L90-L94

https://github.com/shawnscode/crayon/blob/master/src/utils/object_pool.rs#L48-L66

https://github.com/shawnscode/crayon/blob/master/src/utils/object_pool.rs#L164-L174

Description

Unsafe code in ObjectPool has time-of-check to time-of-use (TOCTOU) bug that can eventually lead to a memory safety violation. ObjectPool and HandlePool implicitly assumes that HandleLike trait methods are pure, i.e., they always return the same value. However, this assumption is unsound since HandleLike is a safe, public trait that allows a custom implementation.

Demonstration

  • Crate: crayon
  • Version: 0.7.1
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.46.0 (04488afe3 2020-08-24)
#![forbid(unsafe_code)]

use crayon::utils::handle::{HandleIndex, HandleLike};
use crayon::utils::object_pool::ObjectPool;
use std::sync::atomic::{AtomicBool, Ordering};

#[derive(Debug)]
struct DropDetector(u32);

impl Drop for DropDetector {
    fn drop(&mut self) {
        println!("Dropping {}", self.0);
    }
}

static FLAG: AtomicBool = AtomicBool::new(false);

#[derive(Debug, Clone, Copy, Hash, PartialEq, Eq)]
struct MyHandle {
    indices: [HandleIndex; 2],
    version: HandleIndex,
}

impl HandleLike for MyHandle {
    fn new(index: HandleIndex, version: HandleIndex) -> Self {
        MyHandle {
            indices: [index, index],
            version,
        }
    }

    fn index(&self) -> HandleIndex {
        if dbg!(FLAG.fetch_xor(true, Ordering::Relaxed)) {
            self.indices[1]
        } else {
            self.indices[0]
        }
    }

    fn version(&self) -> HandleIndex {
        self.version
    }
}

impl MyHandle {
    fn with_indices(indices: [HandleIndex; 2], version: HandleIndex) -> Self {
        MyHandle { indices, version }
    }
}

fn main() {
    let mut pool = ObjectPool::new();
    let real_handle: MyHandle = pool.create(123);
    let fake_handle =
        MyHandle::with_indices([real_handle.index(), 12345678], real_handle.version());

    // Segfault with OOB, accessing`pool.entries[12345678]` without boundary checking
    dbg!(pool.get(fake_handle));

    // The bug can be similarly triggered in all other methods of `ObjectPool`
    // that call `handle.index()` in an unsafe block.
}

Output:

[src/main.rs:57] FLAG.fetch_xor(true, Ordering::Relaxed) = false
[src/main.rs:57] FLAG.fetch_xor(true, Ordering::Relaxed) = true
[src/main.rs:57] FLAG.fetch_xor(true, Ordering::Relaxed) = false
[src/main.rs:57] FLAG.fetch_xor(true, Ordering::Relaxed) = true
[src/main.rs:82] pool.get(fake_handle) = Some(

Return Code: -11 (SIGSEGV)

created time in 2 months

startedpdf-rs/pdf

started time in 2 months

pull request commentRustSec/advisory-db

arr: Multiple security issues including data race, buffer overflow, and uninitialized memory drop

I've been recently working on common undefined behavior bug detection for Rust crates. It is still preliminary, but the initial run on crates.io seems promising as the recent stream of PRs show. I'm expecting more PRs like these, and please leave a comment here if you have any feedback as a RustSec maintainer :)

https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/reporting-preference

Qwaz

comment created time in 2 months

PR opened RustSec/advisory-db

chunky: Chunk API does not respect align requirement

Chunk API does not respect the align requirement of types. Unaligned reference can be created with the API, which is an undefined behavior.

Original issue report: https://github.com/aeplay/chunky/issues/2

+13 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0009-chunky

created branch time in 2 months

issue openedaeplay/chunky

Chunk API does not respect align requirement

https://github.com/aeplay/chunky/blob/ef8533aec961eb5f415414dcd81ec4b395bae177/src/value.rs#L29-L41

Description

Chunk API does not respect the align requirement of types. Unaligned reference can be created with the API, which is an undefined behavior.

Demonstration

  • Crate: chunky
  • Version: 0.3.7
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.47.0-nightly (bf4342114 2020-08-25)
#![forbid(unsafe_code)]

use chunky::{HeapStorage, Ident, Value};
use std::rc::Rc;

#[repr(align(256))]
struct LargeAlign(u8);

impl Drop for LargeAlign {
    fn drop(&mut self) {
        println!("Dropped");
    }
}

fn main() {
    let ident = Ident(String::from("ident"));
    let storage = Rc::new(HeapStorage);
    let value = Value::load_or_default(ident, LargeAlign(0), storage.clone());

    // Value reference does not have a correct alignment
    let v = &*value as *const _ as usize;
    println!("{:x}", v);
    assert!(v % std::mem::align_of::<LargeAlign>() == 0);

    // https://github.com/aeplay/chunky/blob/ef8533aec961eb5f415414dcd81ec4b395bae177/src/value.rs#L43-L49
    // Another bug that is not UB: `LargeAlign::Drop` is not called due to incorrect `drop_in_place()` in `Value::drop()`.
    // "Dropped" should be printed otherwise.
}

Output:

555e921bea80
thread 'main' panicked at 'assertion failed: v % std::mem::align_of::<LargeAlign>() == 0', src/main.rs:42:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Return Code: 101

created time in 2 months

PR opened RustSec/advisory-db

arr: Multiple security issues including data race, buffer overflow, and uninitialized memory drop

arr crate contains multiple security issues. Specifically,

  1. It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary.
  2. Index and IndexMut implementation does not check the array bound.
  3. Array::new_from_template() drops uninitialized memory.

Original issue report: https://github.com/sjep/array/issues/1

+16 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0008-arr

created branch time in 2 months

issue openedsjep/array

Multiple security issues including data race, buffer overflow, and uninitialized memory drop

Description

arr crate contains multiple security issues. Specifically,

  1. It incorrectly implements Sync/Send bounds, which allows to smuggle non-Sync/Send types across the thread boundary.
  2. Index and IndexMut implementation does not check the array bound.
  3. Array::new_from_template() drops uninitialized memory.

Demonstration

  • Crate: arr
  • Version: 0.6.0
  • OS: Ubuntu 18.04.5 LTS
  • Rust: rustc 1.47.0-nightly (576d27c5a 2020-08-12)
  • Cargo flags: --release
#![forbid(unsafe_code)]

use arr::Array;
use crossbeam_utils::thread;
use std::rc::Rc;
use std::sync::atomic::{AtomicUsize, Ordering};

static drop_cnt: AtomicUsize = AtomicUsize::new(0);

#[derive(Clone)]
struct DropDetector(u32);

impl Drop for DropDetector {
    fn drop(&mut self) {
        drop_cnt.fetch_add(1, Ordering::Relaxed);
        println!("Dropping {}", self.0);
    }
}

fn main() {
    {
        // https://github.com/sjep/array/blob/efa214159eaad2abda7b072f278d678f8788c307/src/lib.rs#L46-L47
        // 1. Incorrect Sync/Send bounds for `Array` allows to smuggle non-Sync/Send types across the thread boundary
        let rc = Rc::new(0usize);
        let arr = Array::new_from_template(1, &rc);
        let arr_handle = &arr;

        let rc_identity1 = Rc::as_ptr(&rc) as usize;
        let rc_identity2 = thread::scope(|s| {
            s.spawn(|_| {
                // shouldn't be allowed!
                println!("1. Cloning Rc in a different thread");
                let another_rc: Rc<usize> = arr_handle[0].clone();
                Rc::as_ptr(&another_rc) as usize
            })
            .join()
            .unwrap()
        })
        .unwrap();

        assert_eq!(rc_identity1, rc_identity2);
    }
    {
        // https://github.com/sjep/array/blob/efa214159eaad2abda7b072f278d678f8788c307/src/lib.rs#L129-L148
        // 2. `Index` and `IndexMut` does not check the bound
        let arr = Array::<usize>::zero(1);
        println!("2. OOB read: {}", arr[10]);
    }
    {
        // https://github.com/sjep/array/blob/efa214159eaad2abda7b072f278d678f8788c307/src/lib.rs#L111-L127
        // https://github.com/sjep/array/blob/efa214159eaad2abda7b072f278d678f8788c307/src/lib.rs#L165-L174
        // 3. `Array::new_from_template()` drops uninitialized memory because of `*ptr = value` pattern.
        // It also leaks memory since it doesn't call `drop_in_place()` in `drop()`.
        println!("3. Uninitialized drop / memory leak in `new_from_template()`");
        let _ = Array::new_from_template(1, &DropDetector(12345));
    }
}

Output:

1. Cloning Rc in a different thread
2. OOB read: 94648346823632
3. Uninitialized drop / memory leak in `new_from_template()`
Dropping 152521312
Dropping 12345

Return Code: 0

created time in 2 months

PR opened RustSec/advisory-db

Matrix::new() drops uninitialized memory

Matrix::new() internally calls Matrix::fill_with() which uses *ptr = value pattern to initialize the buffer. This pattern assumes that there is an initialized struct at the address and drops it, which results in dropping of uninitialized struct.

Original issue report: https://gitlab.com/dvshapkin/alg-ds/-/issues/1

+13 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0007-alg_ds

created branch time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha 0c82150105a201036b09e5d4dfdef2b2727476d4

Update 0006-alpm-rs

view details

push time in 2 months

PR opened RustSec/advisory-db

StrcCtx deallocates a memory region that it doesn't own

StrcCtx deallocate a memory region that it doesn't own when StrcCtx is created without using StrcCtx::new. This can introduce memory safety issues such as double-free and use-after-free to client programs.

Original issue report: https://github.com/pigeonhands/rust-arch/issues/2

+14 -0

0 comment

1 changed file

pr created time in 2 months

create barnchQwaz/advisory-db

branch : 0006-alpm-rs

created branch time in 2 months

delete branch Qwaz/advisory-db

delete branch : 0006-alpm-rs

delete time in 2 months

create barnchQwaz/advisory-db

branch : 0006-alpm-rs

created branch time in 2 months

delete branch Qwaz/advisory-db

delete branch : 0006-alpm-rs

delete time in 2 months

create barnchQwaz/advisory-db

branch : 0006-alpm-rs

created branch time in 2 months

delete branch Qwaz/advisory-db

delete branch : 0006-alpm-rs

delete time in 2 months

push eventQwaz/advisory-db

Yechan Bae

commit sha b175de4ab4f850c1369f836d6c45e5c6fb38b249

Update 0006-alpm-rs

view details

push time in 2 months

create barnchQwaz/advisory-db

branch : 0006-alpm-rs

created branch time in 2 months

startedperfectblue/ctf-writeups

started time in 2 months

startedbuserror/simavr

started time in 2 months

push eventQwaz/solved-hacking-problem

Yechan Bae

commit sha a17f1f0f2c536ab4194d7fc07a6fe15b303c582a

Participate DEF CON 2020 Quals

view details

push time in 2 months

issue openedpigeonhands/rust-arch

StrcCtx deallocates a memory region that it doesn't own

https://github.com/pigeonhands/rust-arch/blob/8458c22a161cb8996659fd124de49972f8164712/alpm-rs/src/macros.rs#L18-L38

Description

StrcCtx deallocate a memory region that it doesn't own when StrcCtx is created without using StrcCtx::new. This can introduce memory safety issues such as double-free and use-after-free to client programs.

Demonstration

Crate: alpm-rs Version: 0.1.24 OS: Ubuntu 18.04.5 LTS Rust: rustc 1.45.2 (d3fb005a3 2020-07-31)

#![forbid(unsafe_code)]

use alpm_rs::macros::StrcCtx;

fn main() {
    let mut v1: Vec<i8> = vec![1, 2, 3, 0];
    let _ = StrcCtx {
        ptr: v1.as_mut_ptr(),
    };

    // use-after-free in v1
    // v1 and v2 are backed by the same buffer
    let v2: Vec<i8> = vec![4, 5, 6, 0];

    let measure1 = v2[0];
    v1[0] = 123;
    let measure2 = v2[0];

    assert_eq!(measure1, measure2);
}

Output:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `123`', src/main.rs:38:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Return Code: 101

created time in 2 months

delete branch Qwaz/advisory-db

delete branch : rulinalg-201

delete time in 2 months

delete branch Qwaz/advisory-db

delete branch : rocket-1312

delete time in 2 months

delete branch Qwaz/advisory-db

delete branch : ozone

delete time in 2 months

delete branch Qwaz/advisory-db

delete branch : failure-336

delete time in 2 months

startedmicrosoft/winget-cli

started time in 2 months

more