4 ms·

The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many mill

The question is, how much effort is it to keep users safe given language X vs C++. Apparently, when the language is C++, the value is somewhere above many millions of dollars, and we don't know what it is. Can we reasonably expect that price to be lower with language X? For many reasons, I would argue 'yes'.

kllrnohj 8y ago
Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage efficiency & performance also play large roles here.
- staticassertion 8y ago
  To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".
  - kllrnohj 8y ago
    But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning. The only semi-proven way to not get owned at this point is to never go online.
    - staticassertion 8y ago
      I'm not really interested in having a language shootout but I will say that I think you may be misunderstanding Java's history of serialization vulnerabilities.
      - kllrnohj 8y ago
        > I think you may be misunderstanding Java's history of serialization vulnerabilities. Can you elaborate? https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet is just one example compendium. The number of vulnerabilities in this area is huge, across a wide range of libraries. It really is an entire category of exploits at this point, and it's still ongoing (eg, from last year: https://nvd.nist.gov/vuln/detail/CVE-2018-4939 https://nvd.nist.gov/vuln/detail/CVE-2018-4939 )
        staticassertion 8y ago
        You're right that it's a real footgun, the major issues that I'm aware of are in the native serializer, but yeah even the big libraries like Jackson have had issues. I don't consider those on the same level as memory unsafety, personally, but it's not really a meaningful comparison because I'm not going to dig around for numbers and mitigation techniques.
duneroadrunner 8y ago
I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes: DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer()); ... raw_data_.reset(); ... return result; I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-pointers https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-pointers https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-pointers https://github.com/duneroadrunner/SaferCPlusPlus#scope-point... [5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...
- duneroadrunner 8y ago
  Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issue. (Or at least not a typical one.) [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/heap/BlinkGCDesign.md https://chromium.googlesource.com/chromium/src/+/master/thir...
  - ErikCorry 8y ago
    Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.h https://chromium.googlesource.com/chromium/src/+/refs/heads/... The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer.h https://chromium.googlesource.com/chromium/src/+/refs/heads/... See also https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/Allocator.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... and https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...

kllrnohj 8y ago

Sure, but is your goal maximal safety no matter the cost, or are you trying to strike a balance with other factors? If all you want is to keep users safe then it'd be easy - ban JavaScript wholesale. Bam, done, instantly made the web safer & faster. Don't even need to deal with the huge security can of worms that is WebGL, either. But safety is rarely the exclusive factor in play, now is it? Things like memory usage efficiency & performance also play large roles here.

staticassertion 8y ago
To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".
- kllrnohj 8y ago
  But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning. The only semi-proven way to not get owned at this point is to never go online.
  - staticassertion 8y ago
    I'm not really interested in having a language shootout but I will say that I think you may be misunderstanding Java's history of serialization vulnerabilities.
    - kllrnohj 8y ago
      > I think you may be misunderstanding Java's history of serialization vulnerabilities. Can you elaborate? https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet is just one example compendium. The number of vulnerabilities in this area is huge, across a wide range of libraries. It really is an entire category of exploits at this point, and it's still ongoing (eg, from last year: https://nvd.nist.gov/vuln/detail/CVE-2018-4939 https://nvd.nist.gov/vuln/detail/CVE-2018-4939 )
      - staticassertion 8y ago
        You're right that it's a real footgun, the major issues that I'm aware of are in the native serializer, but yeah even the big libraries like Jackson have had issues. I don't consider those on the same level as memory unsafety, personally, but it's not really a meaningful comparison because I'm not going to dig around for numbers and mitigation techniques.

duneroadrunner 8y ago

I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes: DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer()); ... raw_data_.reset(); ... return result; I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-pointers https://github.com/duneroadrunner/SaferCPlusPlus#registered-... [3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-pointers https://github.com/duneroadrunner/SaferCPlusPlus#norad-point... [4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-pointers https://github.com/duneroadrunner/SaferCPlusPlus#scope-point... [5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksGame https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

duneroadrunner 8y ago
Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issue. (Or at least not a typical one.) [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/heap/BlinkGCDesign.md https://chromium.googlesource.com/chromium/src/+/master/thir...
- ErikCorry 8y ago
  Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.h https://chromium.googlesource.com/chromium/src/+/refs/heads/... The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer.h https://chromium.googlesource.com/chromium/src/+/refs/heads/... See also https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/wtf/Allocator.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... and https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...