News for hackers. Stuff that matters.
Re:Chromium project finds that 70% of security defects are m... by saagarjha on Sunday May 24, 2020 @02:19AM (#23289571)
If your type system can handle the case where I can divert code flow along an unsandboxed path by replacing functions from the system libraries even before you can achieve code execution (and long before you certainly though I had code execution), I would like to hear it. But expressed in a less brusque way: yes, encoding state in your type system is generally great, and there is a lot of work being done in languages where you can formally “prove” guarantees about your code. The issue is that your proofs only hold true if the system they run on is correct, you chose exactly the right thing to check, you didn’t just leave out part of the program because you couldn’t fit it into the type system…it’s a nontrivial problem.
Re:Chromium project finds that 70% of security defects are m... by Dylan16807 on Sunday May 24, 2020 @03:32AM (#23289838)
Are you replying to the right comment? It just talks about type systems so you don't forget to check something. No mention of proofs either.
Re:Chromium project finds that 70% of security defects are m... by saagarjha on Sunday May 24, 2020 @03:39AM (#23289861)
Yes, I replied to the one I meant to. The reason we use type systems is that they let us prove things about our code: simple things like “this is a string, not an int”, more complicated things like “this variable cannot be null”, and to the advanced “I have written up a proof in a theorem-proving language that this program will not deviate from the published specifications in these ways”. My point is that the thing that people really want to prove, which is obviously “does this program work and do so correctly”, is fairly impossible to do so in practice due to some of the problems I mentioned. You can only approximate at this along certain domains.
Re:Chromium project finds that 70% of security defects are m... by fauigerzigerk on Sunday May 24, 2020 @07:41AM (#23290843)
I agree. Some lower level library could be rigged to return an Authorized<UserId> when that user is in fact not authorized.

So we would have to make sure that type safety is ultimately backed by a hardware based encryption module, but that's just not where we are today.