Daily C(++) security vulnerability thread

>>60003331
This is fine.

>clang vulnerability is a c vulnerability

>>60003442
This isn't a compiler bug. The description seems to blame the compiler even as it acknowledges that it's a bug in the application.

If you add an unsigned integer to a pointer, of course the result isn't less than the original pointer. So the check isn't needed and the compiler correctly omits it.

>>60003331
I guess the fix is something like

if (segmentEnd - segmentStart <= farPointer.offset) {
    throwBoundsError();
}
word *target = segmentStart + farPointer.offset;
doSomething(*target);

Check for overflow before it happens, not after.

The fix they link to uses a lot of uintptr_t, and it's pointed out that doesn't actually avoid undefined behaviour, it just moves it somewhere else.

>>60003331
No. That code is stupid. C++ or C are not guilty.

>>60003331
>This hurts the NSA/C shill

>>60003331
Sounds like a compiler issue.

>>60003331
>the code would appear to be correct
Correct isn't always good, there are a million better ways to do what this piece of shit code segment does.

I'm not excusing the fact that this really shouldn't be a problem but if you aren't a retard this won't ever happen to you.

>>60003331
>smooth brain compiler doesn't know what to do in an overflow situation
C BTFO

>>60003331
>Apple's compiler and possibly others
>Apple's compiler
>possibly others
One, I like how they didn't bother to check the code with any other compilers to see if it is a common issue.
Two, Apple BTFO.

>>60007642
Oh, they checked it with several versions of GCC and Clang and none of them were affected, so Apple doubly BTFO.

>>60003331
That's working as intended though.

target < segmentStart

can't evaluate to true by definition of the previous line. You're literally adding an offset to your boundary and check if it magically became less then the boundary. Like what? Unless for some reason your offset is negative.

everything is ok on the standard side and compiler side
you shouldn't let any undefined behaviour happen in your programme

>Thus the compiler removes this line
B-B-BUT THE COMPILER IS SMARTER THAN THE PROGRAMMER! Y-YOU SHOUDLN'T TRY TO OPTIMIZE Y-YOUR OWN CODE CAUSE THE COMPILER DOES IT B-BETTER!!!!!

File: Java_Logo.png (17KB, 300x400px) Image search: [Google]

17KB, 300x400px

>>60003331
It's over for C++

File: java_poo.png (87KB, 617x408px) Image search: [Google]

87KB, 617x408px

>this shit again

C++ and especially C more closely model what happens on the silicon. This gives you more control and more opportunities for performance and memory optimization.

The CPU does not bounds check for you. It offers no protection or safety to you what so ever. All 'muh safety' in higher level languages is written by humans who can make mistakes, and compiled by compilers which have holes. It's all an abstraction.

Abstractions can be good. But sometimes you have to code below them for performance and for more direct access to hardware. Hell, C is a portable abstraction of assembler and sometimes you have to ditch C and write assembler.

>hurr durr just use c#/java/python/haskell/javascript/ for everything!

You can't. Somebody somewhere has to write the abstractions so that your favorite language can do the task you naively believe it can do on its own. Those abstractions will be coded in assembler, C, or C++. And I promise you somewhere there will be a security hole or bug. Human beings have no way to verify software under every possible input/output scenario, to say nothing of hardware errors.

>>60008543
>that damage control
Sad