-
-
Replying to @andreasdotorg
That’s a good one and valid, but not one of the bugs anyone else has brought up
. Besides, having bugs isn’t the issue. Resolving, reducing, and remaining well architected is the point.1 reply 0 retweets 4 likes -
Replying to @DonAndrewBailey
Yep. And choosing a language that eliminates whole classes of exploitable vulnerabilities is part of good architecture in my book. I won't deny that OpenSSH is comparatively well written. But writing C is much harder than most people realize. Undefined behaviour everywhere.
1 reply 1 retweet 20 likes -
Replying to @andreasdotorg
Yeah no one is disagreeing. Ignoring better options isn’t the point. Acknowledging that good architecture is a choice is. It isn’t really “harder” now, either. In fact it’s easier today to write safe C than ever before. We know more & have better tools/OS guards. It’s easy now :)
1 reply 0 retweets 3 likes -
Replying to @DonAndrewBailey
Easy really is the wrong word here. And there's still stuff sanitizers and static analyzers don't see. There's still exploits despite mitigations. In most cases, there's just no need to waste cognitive load on low level details. Higher level languages are more economical.
1 reply 0 retweets 8 likes -
Replying to @andreasdotorg
I’m one of the best when it comes to finding 0day in C. :) but I know it’s easy now, to write safe C. You can disagree all you want, but the tools and mitigation’s are available. Our industry failure is not making access simple and straight forward.
2 replies 0 retweets 2 likes -
Replying to @DonAndrewBailey
#define SIZE 8192 char buf[SIZE]; void cpy(struct foo* p, int count) { int n = count * sizeof(struct foo); if ((n < SIZE) && (n > 0)) memcpy(buf, p, n); } Safe or not? Why? How many people can spot this? Which tools? Far from easy.6 replies 1 retweet 10 likes -
Replying to @andreasdotorg @DonAndrewBailey
I might be in the zero category. What seems to be the problem? Is it that in the function declaration foo pointer is not declared const? Or is SIZE the problem?
1 reply 0 retweets 0 likes -
Replying to @lfservin @DonAndrewBailey
Overflow of signed integers is undefined. It is usually twos complement behaviour, as the underlying hardware. However, the compiler has leeway with optimizations. Compile the above with gcc -O0, and it generates safe code. Compile with -O3, gcc eliminates the bounds check!
3 replies 1 retweet 1 like -
Replying to @andreasdotorg
Am I being dumb? Compiling with -O3 (https://godbolt.org/g/WmFJ63 ) turns the comparison into an unsigned compare, so anything negative will be “too big” for the comparison and not hit the memcpy?
1 reply 0 retweets 0 likes
I screwed up the example. If you look closely, you'll notice it will call memcpy for n=0. Which is not what the code intends to do, but not exploitable either.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.