News for hackers. Stuff that matters.
Re:Memory Safe Languages in Android 13 by nneonneo on Thursday December 01, 2022 @08:33PM (#33825612)
Oh absolutely! Here’s an example from 2019: https://www.cve.org/CVERecord?id=CVE-2019-15900

“An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of reporting that the supplied username or group name did not exist, it would execute the command as root.”

Fail to check that your input parsed correctly, wind up with privilege escalation to root.

Re:Memory Safe Languages in Android 13 by netr0ute on Thursday December 01, 2022 @11:07PM (#33826651)
The problem here is that that implementation was written in plain old C and is super unsafe, and is NOT C++. I don't know why C keeps getting confused with C++ because the two are basically totally different now.
Re:Memory Safe Languages in Android 13 by nneonneo on Friday December 02, 2022 @01:17AM (#33827431)
Oh my bad! That must be why C++, a definitely not super unsafe language that is basically totally different from C, lets you do this:

    char buf[10];
    std::cin >> buf;
    std::cout << buf << std::endl;
g++ -Wall -std=c++2a (sorry, I’ve only got GCC 9), no warnings or errors, happily overruns the stack when fed more than 10 characters. This code is essentially equivalent to the C gets(buf) (splitting on whitespace instead of newline), but gets is deprecated and generates big warnings on most modern C compilers. Yet, operator>>(char *) does not.

Sure, you can write secure code in C++. You can write secure code in C too, even if that language is “super unsafe”. But neither language will stop you from writing insecure code either.