61–70 of 104 posts
Earlier quoted context omitted.
Then you have the new problem of restricting its growth and that adds a new failure mode to deal with. The C idiom works fine if you don't have implementation bugs.
Everything has that failure mode, in every language.
Earlier quoted context omitted.
I am by no means a rust developer and asking in ignorance, would this have been a problem had it been written in rust?
In no other mainstream language other than C (and maybe non-idiomatic C++) would this have ever been a problem.
It is not a failure of C that we couldn't improve on it for so many decades.
So the blog mentions that in certain cases you have to decode the punycode from one field to compare it to the value in another field. Would it have been safer to encode the data in the other field to punycode and compare the encoded values? That way a hacker can’t mess with your decoder (where bugs like to lie). But at the other end you risk that your encoder has an issue. I do t know how to judge if those are equal…
I'm not sure if that is the way to go. An allocation per se isn't hard to get right, especially in this case where its scope is well-defined and very limited. What happened here is more the fact that while a single piece of code is easy to get right, a whole codebase isn't. So the only value added by my proposed solution above is that it works in an environment where you can't allocate (e.g. memory-constrained systems where you need to know the required amount of memory statically).
Bottom line: I don't think you can really solve this problem on a technical level.
edit: typo
Earlier quoted context omitted.
I am by no means a rust developer and asking in ignorance, would this have been a problem had it been written in rust?
> would this have been a problem had it been written in rust? The answer would be "it depends on whether you consider denial-of-service a problem". The key detail which makes all the difference is that, unless you're playing with raw pointers (which can only be dereferenced in "unsafe" blocks), the pointer to a buffer slice is always kept together with its length (in a "fat pointer"). Attempting to write through it p…
Earlier quoted context omitted.
I am by no means a rust developer and asking in ignorance, would this have been a problem had it been written in rust?
Rust would take the growable container approach here, so it wouldn't be vulnerable in the same way. There's nothing in C that prevents you from doing this either, but as the parent post mentions it's common style to do this (see also things like snprintf).
Yet these errors consistently happen in C projects of various sizes.
Earlier quoted context omitted.
Rust would take the growable container approach here, so it wouldn't be vulnerable in the same way. There's nothing in C that prevents you from doing this either, but as the parent post mentions it's common style to do this (see also things like snprintf).
> There's nothing in C that prevents you from doing this either Yet these errors consistently happen in C projects of various sizes.
Earlier quoted context omitted.
Rust would take the growable container approach here, so it wouldn't be vulnerable in the same way. There's nothing in C that prevents you from doing this either, but as the parent post mentions it's common style to do this (see also things like snprintf).
> There's nothing in C that prevents you from doing this either Yet these errors consistently happen in C projects of various sizes.
Yes, Rust would eliminate this error, but you can still do it "safer" in C (but you have to give up certain things to do it that way).
Earlier quoted context omitted.
Even in C, you can write an abstraction for a growable buffer. The problem is, you have to make all the rest of the code work with it, rather than a char* or whatnot.
Then you have the new problem of restricting its growth and that adds a new failure mode to deal with. The C idiom works fine if you don't have implementation bugs.
That’s probably where the NSA could be useful because of their big number of competent and sworn to secrecy employees, but nobody can trust that the zero day sent for an opinion will not be used to fuck with a foreign country on day one.