|
|
Log in / Subscribe / Register

DeVault: Announcing the Hare programming language

DeVault: Announcing the Hare programming language

Posted May 4, 2022 10:46 UTC (Wed) by excors (subscriber, #95769)
In reply to: DeVault: Announcing the Hare programming language by wtarreau
Parent article: DeVault: Announcing the Hare programming language

> It's fortunate that the world of secure microcontrollers is not run by people thinking like this or we'd be doomed with secure devices giving off their secrets at the first voltage hickup!

Obviously code that's claiming to provide security features needs to be very careful about all types of bug, because any bug might undermine its security guarantees. But the previous comment mentioned libpng and zlib, which (like the vast majority of libraries) don't claim to provide any security guarantees beyond the API's implicit promise that you can provide them with untrusted input and they'll return either an error code or some valid image/buffer. Memory safety isn't the whole of that, e.g. if libpng supported a "read from local filesystem" chunk type then that'd be a security vulnerability when decoding untrusted images - but unsafe features like that are usually pretty obvious from the documentation or from superficial code review, whereas memory safety errors are ubiquitous in C and very hard to find, so they deserve a lot of attention.

(And even competent people writing critically-important secure firmware would benefit from tools that help with memory safety, to avoid e.g. the use-after-free bug in Apple's SecureROM which broke the secure boot process (https://habr.com/en/company/dsec/blog/472762/).)

> It turns out that 2^53 is too short to store all those possible numbers, it will only accurately represent numbers up to 9007 1992 5475 0991 and above this odd and even numbers will be represented as the same even one. So in such applications if your credit card number is below that value it will be accurately represented, but above this, if it's odd, the next number will be used, and if it's even, you may be charged for the previous number's orders, or be accusated in a court of having been present in a shop or leaving a parking because that number was seen there.

Credit card numbers have a check digit (e.g. https://en.wikipedia.org/wiki/Luhn_algorithm), so an off-by-one error will just result in an invalid card number - it won't be mistaken for someone else's valid card. Still a serious bug that should be fixed, of course, but not really a security bug.


to post comments

DeVault: Announcing the Hare programming language

Posted May 6, 2022 0:49 UTC (Fri) by khim (subscriber, #9252) [Link]

<font class="QuotedText">&gt; Still a serious bug that should be fixed, of course, but not really a security bug.</font>

<p>I think you are mistaken. Lots of cards use <a href="https://en.wikipedia.org/wiki/Payment_card_number#Issuer_...(IIN)">more than 16 digits</a>. What and how JS would do to these numbers is quite a question.</p>


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds