/dcsv/ - Daily C(++) security vulnerability general

Previously Welcome to /dcsvg/ where we discuss security vulnerabilities caused by stagnant C/C++ which is preventable by default by modern languages and their compilers.

>ITT
FreeBSD bhyve Lets Local Users on a Guest System Gain Elevated Privileges on the Host System
securitytracker.com/id/1037400

>Summary
An integer overflow in FreeBSD hypervisor let's virtual machines gain root access to the host system. This means virtual machines cannot be used anymore, thanks to C/C++ being so unsafe

>What caused this
Integer overflow
Languages like Rust or Swift will unconditionally check for overflow, and others like Python 3 and Haskell will avoid overflow entirely by default, via arbitrary precision integers. C/C++ will allow you to release programs with no overflow checks. Thus leading people to suffer from security exploits.

Other urls found in this thread:

huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/
huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/#myth-the-approach-to-overflow-checks-makes-code-slow
bugzilla.redhat.com/show_bug.cgi?id=1428319
blog.sec-consult.com/2017/04/application-whitelisting-application.html
twitter.com/SFWRedditImages

Rust's checked_add() deserves a mention here

Bump

>Languages like Rust or Swift will unconditionally check for overflow
And this is how I know you've never used Rust.
Rust does NOT check for overflow in release builds. If you don't believe me then check it out yourself; oh right, i forgot, you don't even have rustc installed because you're just an angry shitposter who couldn't understand C or Rust because it was too much for your little brain to undersand so you have to stick with something a little easier for you to understand such as Javascript or Python.

On an unrelated note,
>This is legal Rust
unsafe { *(0x123abc as *mut u8) = 0; }
Rust BTFO AND FULL OF SECURITY HOLES

Are you pretending to be retarded or is it deliberate? unsafe blocks let's you safely interface with the rest of your programs.

>Rust does NOT check for overflow in release builds
You don't use release build for debugging and testing. Is that your only defense? Sorry you got busted

>My tests are all encompassing
>Also I'm going to ignore the blatant lie in the OP that was corrected

You still don't seem to understand. Rust only checks for overflow in DEBUG builds.

>C/C++ will allow you to release programs with no overflow checks
And so will Rust.

In case you STILL don't understand, Rust would NOT have prevented this security bug.
The same bug would've happened in Rust.

Unless, of course, you release debug builds lol.

Debug builds and release builds are different, unlike C. You use debug builds during software development you fucking idiot, not the release build.

Debug builds detect these overflows and thus Rust would've prevented this during development.
What lie?

Holy shit, delete this thread op. You're too stupid.

>You use debug builds during software development you fucking idiot, not the release build.
No shit fucktard.

>Debug builds detect these overflows and thus Rust would've prevented this during development.
Nope.
The bug would not have been caught because it would not have been triggered.
It can only be noticed when it actually gets triggered.

You're just showing your stupidity more with each post.

That was a nice demonstration of damage control, nsa shill

>The bug would not have been caught because it would not have been triggered.
What?
huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/

Educate yourself

>b-but rust won't solve this problem
hmmm
#[no_mangle]
pub fn checked(x: i32, y: i32) -> i32 {
x + y
}

#[no_mangle]
pub fn unchecked(x: i32, y: i32) -> i32 {
x.wrapping_add(y)
}


hmmm
pub trait CheckedAdd: Add {
fn checked_add(&self, v: &Self) -> Option;
}

hmmm
[@arch ~]$ cat main.rs
fn add(a: u32, b: u32) -> u32 {
a + b
}

fn main() {
println!("{}", add(0xffffffff, 2));
}
[@arch ~]$ rustc main.rs
[@arch ~]$ ./main
thread 'main' panicked at 'attempt to add with overflow', main.rs:2
note: Run with `RUST_BACKTRACE=1` for a backtrace.
[@arch ~]$ rustc main.rs -C opt-level=3
[@arch ~]$ ./main
1
[@arch ~]$


Try again

>Having to call a special function to check for overflow in release
>Ignoring c compilers have a similar function
>Doesn't see the correlation between these two situations
user, it's time to stop same fagging.

>thread 'main' panicked at 'attempt to add with overflow'
hmmmmmmmm

>[@arch ~]$ rustc main.rs -C opt-level=3
[@arch ~]$ ./main
1
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

Tell me. Do you release debug builds?

>software development with release modes
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

I'm guessing you are one of those ""programmers"" that use -O3 while development as well. Do you also use Arch Linux?

Are you seriously this stupid?

>Develop with debug builds
>Overflow never gets triggered (most likely case)
>Therefore never caught
>Release optimized build
>Bug gets triggered some time later in production
You get it now?

>Develop with debug builds
>>Overflow never gets triggered (most likely case)
Except it did in your own example hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

You never answered my question. Do you also use Arsch Linux?

*

I don't see the problem with O3, user
~/Desktop/does it$ gnatmake addition_is_hard.adb -O3 -s
gcc-5 -c -O3 addition_is_hard.adb
gnatbind-5 -x addition_is_hard.ali
gnatlink-5 addition_is_hard.ali -O3
~/Desktop/does it$ ./addition_is_hard

raised CONSTRAINT_ERROR : addition_is_hard.adb:4 overflow check failed

>I don't see the problem with O3
People that programmed for more than a month or two know full well not to use -O3 even for the release build let alone debugs

>Except it did in your own example
That's because I explicitly check for the case.
You're basically saying that in order to prevent overflow bugs in Rust, you must write test cases to explicitly cover the case, otherwise it'll slip through to production and stay there.
I know you don't develop software, but 99% of the time overflow bugs don't usually get triggered by accident in development.

Now, that said, how do we check for overflow bugs in C/C++?
>write test cases to explicitly check for the overflow

So if the freebsd devs didn't check for overflow in their hypervisor written in C, then they wouldn't have checked for overflow in their hypervisor written in Rust.

Seems like to me that the bug would have happened no matter if it was in C, C++, or Rust.
Seems like to me that this bug was the fault of the developers, not the language. Or if you prefer: Rust is insecure garbage just like C and C++.

>Do you also use Arch Linux?
Yes. I thought that was already obvious from my hostname.

sounds like a "rust-ism", unless you have an example of why I shouldn't. I'll wait.

>You're basically saying that in order to prevent overflow bugs in Rust, you must write test cases to explicitly cover the case,
No, Rust builds check by default, much like swift and haskell
>I know you don't develop software, but 99% of the time overflow bugs don't usually get triggered by accident in development.
This coming from a ""programmer"" that use -O3 in development and uses (((Arsch))) Linux. No wonder whole Sup Forums makes fun of Arch toddlers

>Seems like to me that the bug wou[spoiler]l[/spoiler]d have happened no matter if it was in C, C++, or Rust.
No. For the thousandth time, debug builds check for overflows. Also Rust has safe adders

Let's put this to bed right now.

It is possible and feasible to develop secure software in C(++). Most bugs (security) or otherwise in C(++) and many other "modern" languages all have a common cause: time restrictions.

>hey man, have you tested that new script you pushed yet? We've gotta deploy in two days.
>yea I gave it some quick testing; they only added this requirement yesterday!

>meanwhile there's a '$' missing causing a comparison to be made to a literal instead of a variable

Mismanagement is the true cause of uncaught software errors.

>but open sores has dis two

(F)OSS projects have "management" and deadlines too. Also:
>Most

I don't use -O3 in development you fucking retard. That's someone you pulled out of your own ass.

>No, Rust builds check by default
Correct. Rust checks for overflow WHEN IT HAPPENS.
If you don't trigger the overflow, the program never panics and you never notice the bug.
How fucking dumb are you that you can't understand this simple concept?

>how fucking dumb
It's a rust shill, that tells you everything you need to know.

All the design/discussion/implementation of this scheme for handling integer overflow would be wasted if it didn’t actually find any bugs in practice. I personally have had quite a few bugs found nearly as I write them, with expressions like cmp::max(x - y, z) (they never hit the internet, so no links for them), especially when combined with testing infrastructure like quickcheck.

The overflow checks have found bugs through out the ecosystem; for instance, (not exhaustive!)

the standard library
the compiler
the built-in benchmark harness
Servo
image
url
webrender

Beyond Rust, there’s a lot of evidence for the dangers of integer overflow and desire for detecting/protecting against them. It was on the CWE/SANS list of top 25 errors in 2011, languages like Swift will unconditionally check for overflow, and others like Python 3 and Haskell will avoid overflow entirely by default, via arbitrary precision integers. Furthermore, in C, several compilers have options to both make signed overflow defined as two’s complement wrapping (-fwrapv) and to catch it when it does happen (-fsanitize=signed-integer-overflow).

But I'm also a Rust shill though.
The difference is that is a dumb fucking Rust shill while (me) is a smart Rust shill who actually knows their shit.

>This hurts the C shill

Hello samefag.

It doesn't hurt us at all.
We're aware of how Rust handles integer overflow. It's just you who doesn't understand how Rust handles integer overflow.

Every language has had and continues to have privilege escalation bugs. If you knew how to use fucking Google you would know this.

Stop being a toddler and posting these stupid "muh C++ security!" posts every damn day.

Is that how backpedaling works in 2017?

Backpedalling? where?
My first post claimed that you are wrong about how Rust handles integer overflow, and it has remained that throughout all my posts.
Please, point to the post where I changed my goalposts.

as crazy as it sounds, i'm honestly not convinced security is an interesting or important problem

we're living in a timeline where a significant number of technologists think a cyborg god is going to devour our souls within twenty to eighty years

i think i'd rather just work on numerical computing

It handles overflow by panicking, what are you talking about?

*in debug

Only in debug builds, and only when you trigger the overflow.
If you don't write a test case to trigger the overflow, it'll make it into the release builds and be triggered later on in production.

C has UBSan, which also checks for integer overflow in debug builds when enabled.

Yes
Doesn't check by default

Exactly, so if you don't bother to check for overflow in test cases, you leak the bug into release.

It's just like with C; if you don't bother to check for overflow in test cases, you leak the bug into release.

You don't seem to understand that the overflow can only be caught when and only when the overflow actually happens.

>so if you don't bother to check for overflow in test cases, you leak the bug into release.
Why do I have to bother? It should check by default with no addons or anything - which rust does

>Overflow not triggered in debug
>Move to release
>Overflows silently in release
You're dense, dude.

Except it did in your example there are you trying to fish more you's?

That's not me. I'm the one you ignored for mentioning test cases don't guarantee full coverage, because it's true and disproves everything you've said.

Are you the one who got BTFO in ?

>I'm arguing with myself
Retard. was OP. I know you're also probably OP because you're a shitposting troll.

lesswrong was a mistake

I give up. You're just wasting my time.
You're too retarded to argue with.

Consider this more realistic example then:

[@arch ~]$ cat main.rs
fn main() {
let args: Vec = std::env::args().collect();

if args.len() < 3 {
println!("Expected 2 arguments");
std::process::exit(1);
}

let a: u32 = args[1].parse().unwrap();
let b: u32 = args[2].parse().unwrap();

println!("{}", a + b);
}
[@arch ~]$ rustc main.rs
[@arch ~]$ ./main 1 2
3
[@arch ~]$ # Seems fine to me. Lets release it.
[@arch ~]$ rustc main.rs -C opt-level=3

... later on someone elses machine ...

[@arch ~]$ ./main 1 2
3
[@arch ~]$ ./main 4294967295 2
1
[@arch ~]$ # WOAH HANGON I THERE, HOW THE FUCK DID THIS GET PASSED DEBUG I THOUGHT RUST CHECKED FOR OVERFLOW HURFDURFDURF

fn main() {
let args: Vec = std::env::args().collect();

if args.len() < 3 {
println!("Expected 2 arguments");
std::process::exit(1);
}

let a: u32 = args[1].parse().unwrap();
let b: u32 = args[2].parse().unwrap();

print_sum(a,b);

}

#[no_mangle]
fn print_sum(x :u32, y:u32){
print!("{}", x+y);
}

thread 'main' panicked at 'attempt to add with overflow', main.rs:18


HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

idiot

See? you've had to explicitly check for the overflow case in the debug build.
You would've missed it if you didn't think to check for it.

Rust doesn't add any more protection from integer overflow than C does.
If you don't check for it, you miss it.

Unless you release debug builds which is stupid.
Anyway, I'm pretty convinced right now that you're just doing this on purpose.

>you had to explicitly check
hmmmm
fn main() {
let (x,y) :(u32,u32) = (4294967295,2);
print_sum(x,y);

}
fn print_sum(a :u32, b:u32){
print!("{}", a+b);
}
cargo run
Compiling tests v0.1.0 (file:///home/user0/devel/proj/tests)
Finished dev [unoptimized + debuginfo] target(s) in 0.54 secs
Running `target/debug/tests`
thread 'main' panicked at 'attempt to add with overflow', src/main.rs:7
note: Run with `RUST_BACKTRACE=1` for a backtrace.

>Finished dev [unoptimized + debuginfo] target(s) in 0.54 secs
Are you actuallye not able to read and understand english?

You're not even coherent any more. You need to turn off your computer

Yes.
Don't you see? you wrote code to specifically trigger the overflow. If you didn't do that, which most people don't, you'd leak the overflow bug into release.

Are you joking?
>you wrote code to specifically trigger the overflow
hmmmm
fn main() {
let args: Vec = std::env::args().collect();

if args.len() < 3 {
println!("Expected 2 arguments");
std::process::exit(1);
}

let a: u32 = args[1].parse().unwrap();
let b: u32 = args[2].parse().unwrap();

print_sum(a,b);

}

fn print_sum(x :u32, y:u32){
print!("{}", x+y);
}
cargo run 444444444444444444444412 99
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/tests 444444444444444444444412 99`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: Overflow }', /buildslave/rust-buildbot/slave/stable-dist-rust
c-linux/build/src/libcore/result.rs:868
note: Run with `RUST_BACKTRACE=1` for a backtrace.

>debug build on input you know will break

>Are you joking?
Are you?
The argument is that the actually SHIPPED binary doesn't do any checks.
So you only ever have an advantage IF you trigger the bug in a debug build.

So showing that it works if your test
triggers a bug would also work in C/C++.

The only advantage is that in rust it will trigger in slightly smaller testcases, since it's catched where it happens

This is like someone with schizophrenia trying to explain to the person next to them, that their shoe is plotting against them.

The difference is Rust panics and you can catch exception. C will give you random number which has lead to the bug in question

Hey guys, first year CS student in uni, i'd probably be able to figure out how to do everything in OP's picture, but i don't understand anything in this thread, am i fucked?

The thing is, that a SHIPPED binary will do the same fucking thing, since it doesn't do the check.
Are you really not seeing the difference between a debug build and a shipped build?

>hey guys let's argue about some inconsequential, arbitrary subject to the point both of us get pissed off

retards

This is not a release build and yet the program panics.

Also are their solutions to OP's picture out there?

>The difference is Rust panics and you can catch exception.
And so will C with UBSan.
>inb4 not by default
If your intention is to catch overflow bugs, then it doesn't make a difference in either language; it's just in C you pass an extra flag to the compiler.

>and you can catch exception
Rust doesn't have exceptions.

>C will give you random number
Undefined number*

>which has lead to the bug in question
And rust will also give you an undefined number in release builds, which would trigger the same bug.

What's the difference between string and char[]?

>I don't know how to do these things with my little experience
>Am I fucked

>but i don't understand anything in this thread
Don't worry, none of us do.

>not a release
That's exactly the problem you bonehead idiot.

If you have a testcase that catches the bug in a debug build, so will valgrind or anything else used to analyze test builds for projects written in C/C++.

Unless your SHIPPED fucking binary is capable of catching this bug reliably without significant performance hits, your entire arguments is fucking moot, since it reduces to "I don't need to start valgrind for my testing".
It's a nice step, but nothing special.

>Rust prgram will panic with a catchable exception
>C will give you an undefined number
I'm sorry was that supposed to be a damage control?

>Rust doesn't have exceptions
.except("fuck off")

>Specifically building to catch overflows in rust
>Any different that specifically building to catch overflows in c
You're literally insane.

Rust has error handling. What's the equivalent in C?
>Protip
Nothing

>Unless your SHIPPED fucking binary is capable of catching this bug
Once again you fucking faggot, do you know when people publish release builds?

Pick me! Pick me! Is it after they run their test that has no guarantee of triggering every issue?

You seem to be confusing exceptions with Option/Results. They're not the same thing.

But nice try evading the main point of my post.

>Rust error handling mechanism: Return values
>C error handling mechanism: Return values
The only difference is that Rust makes it more convenient to define and return option/result objects because of generics and tagged unions.
C++ also has generics and the is getting std::optional and std::variant in C++17.

>Once again you fucking faggot, do you know when people publish release builds?
After testing.
Now point me to a project that has 100% test coverage.
Protip: You can't because there is none.

It's after they you have tested everything in the debug builds, you release a beta for bug squash period

>Tested everything
Nice perfect world, schizo.

>It's after they you have tested everything in the debug builds
>everything
Link me a project that has done this.

When they think they finished fixing bugs.
Or when management tells them to do it.

You know, you ASUME that there's a testcase that will catch this bug.
Good riddance, then your language has no influence on whether that's found.

Saying that your test builds are better is useless.
IF any testcase triggers the bug, there's no reason it ever escapes. It doesn't matter if valgrind finds it or the runtime.

Literally the only thing you are saying is that you moved something that existed for a long time into the runtime, which makes debugging builds horribly slow when not testing for these error classes (so any non-trivial test will take ages to run).

So again: If you testcase can trigger it, you will find it, be it in rust or C/C++.
If your testcase doesn't find it, rust will behave the same.

Unconditionally checking every integer operation for overflow leads to slower programs. Most integer operations will never overflow, and can be trivially proven not to do so. If you actually read over your code and analyze how your variables are used, you can avoid generating a lot of stupid bugs. Stop being a stupid human and using your language as a crutch.

Your tests are not all encompassing. You just think they are.

Ruby, I don't think you know how the meme arrows work.

>Your tests are not all encompassing. You just think they are.
Why does it not surprise me that a namefag doesn't see irony?

But we should really have tools that can enforce at least some inverval bounds on variables, so we have static tests for those trivial proofs in code.

I think you're responding to the wrong person.

huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/#myth-the-approach-to-overflow-checks-makes-code-slow

This is the most laughable thing about the """"""""Rust security experts"""""""". 90% of the time it's a logic bug that leads to privilege escalation.... retards think they can rewrite shit in Rust and magically avoid these flawed checks.. oh boy have I bad news for them.

>Performance is one of the main motivations for checks being disabled in release builds by default
>disabled in release builds

>souce: my ass
Here's another one, enjoy
bugzilla.redhat.com/show_bug.cgi?id=1428319

Reminder that these threads are made by 1 (one) deranged individual who is probably on Mozilla's payroll to spread FUD about C/C++.

How much does the NSA pay you to keep the attack surface (C/C++ software) alive?

>There are NSA shills ITT RIGHT NOW that will defend C after THIS

>samefagging this hard

After what?

DOUBLE FREE IN THE KERNEL THAT CAUSES RACE CONDITION

>he doesn't use -fPIE

surely another language will solve all problems
blog.sec-consult.com/2017/04/application-whitelisting-application.html

>DOUBLE FREE IN THE KERNEL THAT CAUSES RACE CONDITION

I don't quite get how this happens, but do people that shill "save" langauges that hard not get that this problem wouldn't be cought by their meme language since they have to escape their *save* part to implement a bunch of stuff with performance acceptable for a kernel?

freebsd doesn't even have aslr by default