[userbinator]

Seems like the buffer for storing the password was changed to be dynamically allocated

When I see things like this, the first question I have is why? A password isn't going to be long enough to require dynamic allocation, so just use a fixed-size buffer. 255 is already generous and a good round number. The best solutions are often also the simplest.

[AlexanderDhoore]

This is why I love working in embedded. Our clients would never complain about these kinds of reasonable restrictions. There are tons of limits like this in our machines, which nobody notices but make my life much easier.

I guess things are different in the Linux/PC software world.

[tgv]

It also might explain the S in IoT.

[ilyt]

I'd say not anymore, average microcontroller used in IoT got fat enough, nowadays even smaller chips come with AES acceleration too.

I'm frankly surprised some proper standard didn't pop up already, I guess closing the users in your own ecosystem as fast as possible is priority in the industry.

Good 80-90% of devices could be just "an MQTT connection + a bit of code to pair it up initially and feed server data" + a bunch of templates for how typical services should present themselves (so a light will just work with any compatible "control center"). Then just sell user subscription to your cloudy cloud IFTTT clone or a separate box to put in house that does the same job.

[raldi]

> When I see things like this, the first question I have is why?

Perhaps because they were still fighting the last war, where they were hurt by a greater-than-255-character buffer overflow vulnerability.

[insanitybit]

One reason I'd like to write passwords directly to a heap allocated buffer would be so that I can limit where that password exists in memory, ensure it's zero'd appropriately, prevent it being paged to disk, etc.

[imron]

> When I see things like this, the first question I have is why?

My default assumption is three letter agencies surreptitiously adding back doors.

[bell-cot]

With how many careless programmers there are, writing massive quantities of security-critical code...why would they bother? (Outside of a maybe a few narrow, high-value contexts.) That's like surreptitiously working to make sure that there are plenty of cat pictures on the web, and that water flows downhill.

[trashtester]

As a default assumption, this may be a bit conspiratorial. Inserting something like this into a git repo is relatively easy to track, and a given "contributor" could not do many such things without being caught. Not saying we should ignore the possibility, though...

But there are plenty of ways for such agencies to gain similar access, including any kind of closed code in BIOSes, drivers, firmware etc. Or by taking control of select infra, and injecting MITM features there (that would remain stealthy, and only activate for very select targets.)

[Izkata]

> Not saying we should ignore the possibility, though...

Two suspected and one confirmed attempt in linux from a post 6 years ago: https://www.reddit.com/r/linux/comments/54in5s/the_nsa_has_t...

Found this while looking for a more recent one I vaguely remember involving a bad implementation of I think /dev/random

[generalizations]

This should be a reasonable position to take. There's means and motivation present. The threat model should be taken seriously.

[marcosdumay]

Because then you'll have another vulnerability created by too long passwords.

[GTP]

Not necessarily, as you can put a limit on how many characters you read from the shell. But you're right that you can screw up in both cases, I would just say that if you have a fixed length for the buffer it is a bit easier to handle it correctly.

[nicoburns]

Using a language that stores the length as part of the type is the real fix here.

[kccqzy]

So are you proposing to use dependently typed languages then? Typical languages like C++ don't make it very convenient.

    template<size_t N>
    void do_something(char (&s)[N]) { ... }

Now when you have a string of unknown length, how do you reify it with that template? In practice languages then have to keep around an unknown type argument at runtime. This is incompatible with most languages where types aren't known at runtime.

[AshamedCaptain]

Why overcomplicate things so much? He probably just meant to use std::string. Programs like this definitely don't need to care about the few dozen bytes added by std::string overhead.

[umanwizard]

std::string stores the length as part of the value, not as part of the type. (That’s probably what nicoburns meant, but it’s clear what caused the confusion).

[GTP]

This for sure, but the codebases that we alreaduly have in C/C++ aren't going anywhere anytime soon.

[pjmlp]

Those that are proper C++ would use a string type instead of raw C strings.

And if those developers care about security, bounds checking would be enabled.

As for C there is hardly anything we can do other than keep fixing exploits until hardware memory tagging becomes a common feature across all major platforms.

[scoutt]

You still need to compare the length against a maximum, wherever it's stored.

[GTP]

No, in that case the language will do that for you.