Jump to page: 1 26  
Page
Thread overview
[OffTopic] A vulnerability postmortem on Network Security Services
Dec 02, 2021
Paulo Pinto
Dec 02, 2021
bauss
Dec 02, 2021
user1234
Dec 02, 2021
Imperatorn
Dec 02, 2021
Johan
Dec 02, 2021
Paulo Pinto
Dec 02, 2021
Tejas
Dec 02, 2021
Paul Backus
Dec 02, 2021
jmh530
Dec 02, 2021
Tejas
Dec 02, 2021
bachmeier
Dec 03, 2021
Tejas
Dec 04, 2021
bachmeier
Dec 04, 2021
rikki cattermole
Dec 05, 2021
Greg Strong
Dec 05, 2021
rikki cattermole
Dec 05, 2021
Greg Strong
Dec 06, 2021
rikki cattermole
Dec 05, 2021
SealabJaster
Dec 05, 2021
Paul Backus
Dec 06, 2021
SealabJaster
Dec 06, 2021
IGotD-
Dec 08, 2021
jmh530
Dec 08, 2021
H. S. Teoh
Dec 08, 2021
Timon Gehr
Dec 10, 2021
Nick Treleaven
Dec 03, 2021
bauss
Dec 02, 2021
H. S. Teoh
Dec 02, 2021
Tejas
Dec 02, 2021
H. S. Teoh
Dec 02, 2021
Greg Strong
Dec 02, 2021
Paul Backus
Dec 08, 2021
Nick Treleaven
Dec 02, 2021
H. S. Teoh
Dec 02, 2021
Imperatorn
Dec 02, 2021
H. S. Teoh
Dec 02, 2021
IGotD-
Dec 02, 2021
Paulo Pinto
Dec 02, 2021
H. S. Teoh
Dec 03, 2021
Paulo Pinto
Dec 03, 2021
Paulo Pinto
Dec 03, 2021
Paulo Pinto
Dec 03, 2021
Paulo Pinto
Dec 03, 2021
Paulo Pinto
Dec 03, 2021
Kagamin
December 02, 2021

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

December 02, 2021

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

Seems like a bounds-checking error and thus would be caught without @safe even.

December 02, 2021

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

Bottom line:
Use D instead of C 😎

December 02, 2021

On Thursday, 2 December 2021 at 10:58:10 UTC, bauss wrote:

>

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

Seems like a bounds-checking error and thus would be caught without @safe even.

I was thinking about stronger typing of the union members + better encapsulation and better way to init the struct (better than the memcpy).

December 02, 2021
On Thu, Dec 02, 2021 at 08:09:18AM +0000, Paulo Pinto via Digitalmars-d wrote:
> Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.
> 
> https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html
> 
> Hence why @safe matters.

Another nail in the coffin of C.  Still many more nails to go, but the inevitable draws ever nearer.


T

-- 
Without geometry, life would be pointless. -- VS
December 02, 2021
On Thursday, 2 December 2021 at 11:27:01 UTC, H. S. Teoh wrote:
>
> Another nail in the coffin of C.  Still many more nails to go, but the inevitable draws ever nearer.
>
>
> T

Would it be impossible to add bounds checking in C?

It's been over 4 decades and it seems like there is some profound resistance to add this.
December 02, 2021

On Thursday, 2 December 2021 at 11:01:07 UTC, Imperatorn wrote:

>

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

Bottom line:
Use D instead of C 😎

Sorry to rain on the party here, but D is of course not at all immune to this problem.
It was not hard to find out-of-bounds memory access in the D compiler, using the fuzz techniques mentioned in the article.

https://johanengelen.github.io/ldc/2018/01/14/Fuzzing-with-LDC.html
https://github.com/dlang/dmd/pull/7050

Note the discussion of bounds checking in the PR...

-Johan

December 02, 2021
On Thursday, 2 December 2021 at 11:44:28 UTC, IGotD- wrote:
> On Thursday, 2 December 2021 at 11:27:01 UTC, H. S. Teoh wrote:
>>
>> Another nail in the coffin of C.  Still many more nails to go, but the inevitable draws ever nearer.
>>
>>
>> T
>
> Would it be impossible to add bounds checking in C?
>
> It's been over 4 decades and it seems like there is some profound resistance to add this.

Yes, mostly due to culture, all major C compilers have extensions and secure libraries.

For example,

https://access.redhat.com/blogs/766093/posts/1976213

https://access.redhat.com/blogs/766093/posts/3606481

https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html#Object-Size-Checking

Red-Hat and Android make use of FORTIFY_SOURCE among other features, for example,

https://source.android.com/devices/tech/debug/native-memory

Oracle has given up almost a decade ago, that is why Solaris on SPARC is basically a C Machine, thanks ADI.

https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html

While Intel has borked their MPX implementation, ARM also got into the C Machine concept, which is being adopted across mobile OSes.

https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

https://source.android.com/devices/tech/debug/tagged-pointers

So eventually hardware memory tagging will take care of killing processes that don't behave, and we will have C Machines with memory tagging, because the powers that could fix the language don't want to (ISO C, WG 14).

December 02, 2021

On Thursday, 2 December 2021 at 12:15:38 UTC, Johan wrote:

>

On Thursday, 2 December 2021 at 11:01:07 UTC, Imperatorn wrote:

>

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

[...]

Bottom line:
Use D instead of C 😎

Sorry to rain on the party here, but D is of course not at all immune to this problem.
It was not hard to find out-of-bounds memory access in the D compiler, using the fuzz techniques mentioned in the article.

https://johanengelen.github.io/ldc/2018/01/14/Fuzzing-with-LDC.html
https://github.com/dlang/dmd/pull/7050

Note the discussion of bounds checking in the PR...

-Johan

Oh well

December 02, 2021

On 12/2/21 7:15 AM, Johan wrote:

>

On Thursday, 2 December 2021 at 11:01:07 UTC, Imperatorn wrote:

>

On Thursday, 2 December 2021 at 08:09:18 UTC, Paulo Pinto wrote:

>

Google's Project Zero goes through a memory corruption exploit on Network Security Services, where despite all static analysers, fuzzers and code reviews, it flew under the radar.

https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html

Hence why @safe matters.

Bottom line:
Use D instead of C 😎

Sorry to rain on the party here, but D is of course not at all immune to this problem.
It was not hard to find out-of-bounds memory access in the D compiler, using the fuzz techniques mentioned in the article.

The D compiler is not @safe.

Using D isn't enough, you need to use @safe D.

Even that isn't enough, because most of the time people misuse @trusted (because it's so easy to misuse).

-Steve

« First   ‹ Prev
1 2 3 4 5 6