|
From the CP newsletter about how a new language will fix all problems that come from C++
Swift the best choice to succeed C++, Apple says | InfoWorld[^]
For a few years I was a principle security reviewer for a financial application. It wasn't written in C++ but that certainly didn't make me think that it wasn't possible to introduce security problems.
And I looked up top security problems in 2023. I only got above halfway down the list but I didn't see any that seemed to be caused by C++ pointer errors.
Qualys Survey of Top 10 Exploited Vulnerabilities in 2023 | Qualys Security Blog[^]
Matter of fact when I was a security reviewer I got to see a private study produced by a company that made quite a bit of money from cleaning up security problems that companies had.
And in that study something like 90% of the problems were caused by internal bad actors.
Rather pointless to obsess about whether your pointers are safe when the CEO is using internationally set up companies to ship fake orders and thus prop up the companies stock (real case.)
|
|
|
|
|
Back when I was a teenager and the Internet was a fresh thing to most people I spent my time getting into systems I didn't belong in.
And most of the time I got there by using buffer overrun attacks on services that should have never been Internet facing to begin with, like a network print daemon (citing a specific example that allowed me to identd on efnet as freshmeat@usda.gov )
My point is, this used to be common, at least in the wild west days of the Internet, so I wonder how much of the fact that it doesn't seem to be so common now has to do with better practices, better libraries, and such in C and C++. For example, Microsoft produced a bunch augmented functions to the C runtimes that take lengths which they check so you can't overrun them. Things like strcat_s? and stuff. I don't really use them because I don't do a lot of C++ on Microsoft's compiler, but it made me think of that.
Also, probably less services are written in C or C++ now that machines are cheaper and faster.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I don't use the strcat_s family of functions either. I find that strncpy, strncat, and snprintf handle things quite well.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
TBH, so do I. If I was pressed I probably couldn't tell you what the actual benefit of the _s functions are - only what MS presented them as.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I believe their claim is they use sizes that are automatic so you can't "lie" to them. My view is this is C/C++ and I trust myself. I wouldn't use the language if I didn't.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It might not be your code, but a system library that has the problem.
|
|
|
|
|
Greetings Kind Regards char* ? wchar_t* ? Why not std::basic_string<char> std::basic_string<wchar_t> .
|
|
|
|
|
You'd be surprissed how many services are "internet" facing even though they should never be... not even basic security considered. Recently had an incident where a RDP connection was possible to a server holding / running finicial data for multiple companies... not even a FW or anything inbetween... scary sometimes
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
I'm not surprised.
But you have understand that in 1994, almost everyone was vulnerable.
It's relative.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I would say that you have a category error here. One must divide the security breaches into unauthorized access, and authorized access to perform unauthorized actions. The first encompasses all "hacking" attempts (buffer overruns, SQL injection, etc. etc.), while the second encompasses the "inside jobs".
Secure languages are an attempt to mitigate "hacking". Proper procedures are one way to mitigate "inside jobs" and designing them is at least as difficult as designing a secure language.
C++ already has the neccesary mechanisms for producing robust code - unique_ptr<>, shared_ptr<>, string, vector, etc. The problem IMO is the legacy code ported from C, and new code that uses ordinary pointers and buffers in a misguided attempt at optimization.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Quote: C++ already has the neccesary mechanisms for producing robust code - unique_ptr<>, shared_ptr<>, string, vector, etc. The problem IMO is the legacy code ported from C, and new code that uses ordinary pointers and buffers in a misguided attempt at optimization. The problem is also code written before C++11, when those pointers became available. It won't get retrofitted unless it has problems attributable to pointers, which it typically won't given the time it's had to soak. For new code, I think failing to use the things you mentioned is less a case of misguided optimization and more one of ignorance on the part of those who never progressed beyond the pure C way of doing things.
|
|
|
|
|
Without pointers, programming languages are pointless.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
CPallini wrote: Without pointers, programming languages are pointless pointerless. FTFY
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
It's just too easy to make a serious mistake even if you do know what you are doing and are extremely good at it. Meanwhile, the penalty for near any such failure is near inevitably RCE or privilege elevation with both basically throwing the doors wide open for the barbarians at the gates.
It's also "just how things are done", using pointers and pointer arithmetic. Maybe you can make a performance argument in a very few cases. (Why are they pythoning all the ML stuff instead of C++?) Mostly though, we aren't seeing superior products as a result, but inferior ones, not in terms of performance, but security. And it's just not worth it anymore to use these unless you just don't have a choice. The situations where that holds true are shrinking fast. They'll be gone inside a decade when I think it will be totally reasonable to expect something like a .NET-on-chip and other similar such inroading into embedded development.
|
|
|
|
|
If you're looking at technical issues leading to security issues, then null-terminated buffers are the number one problem, followed by use after free and then reading uninitialized buffers.
If you're looking at all sources of security issues, people are by far the number one cause of security incidents.
|
|
|
|
|
Here is a different view:
Ever since programming began, defeating compiler-enforced typed safety became an obsession of many programmers. And IMO pointers were their main tool as it gave the programming arena a natural layer-of-indirection. Be that as it may, thankfully, there is a great movement in C++ from programming with pointers, pointer semantics, to value semantics. With that, C++ "is like a different language" paraphrasing Bjarne. Value semantic programming gets really difficult, but that laudable goal is the re-assertion of compiler-enforced type safety without man-in-the-middle pointers. And compiler-enforced type safety was the original goal of C++ which Bjarne has single-handedly urged the C++ maintainers to adhere to over the years. IMO this will separate the programming sheep (get it done fast) from the goats in the future.
Just saying.
|
|
|
|
|
Sticking to software development, pointers are obviously not a problem, bad programmers are a problem (cretins disguised as geniuses often are a very big problem). Bad management (forcing people to cut corners) is also to blame. And sometimes there are royal mess-ups in initial design.
Of course the golden rule of any organization is to blame anyone and anything for your mess, but not admit your own fault, and pointers are a bit like quantum superposition, everyone heard of it, few understand it, so it is a perfect scapegoat.
|
|
|
|
|
It depends on what they are pointing to …(?)
I had just switched companies. I was about a year and a half out of school with pretty solid C skills. A senior programmer at the new company who was new to C asked me to review a C module he was implementing.
All of the code looked pretty solid. The module used a fairly large struct for tracking its data. Every method in the module accepted a pointer to the struct type or else used a global pointer (too long ago).
After reviewing the code, I asked him “Where is the memory allocated to actually hold the struct data?”. Huh?
We added a global variable declaration of his struct type and initialized the global pointer with its address and everything worked fine.
My tenets when dealing with pointers:
1. When declaring the pointer, the * is part of the type.
int* justAPlainOldVariableOfTypeIntPointer;
int** justAPlainOldVariableOfTypeIntPointerPointer;
- A pointer is a leash
- A pointer is NOT the dog!(or cat but who leashes their cat, it is undignified)
- When writing or reading code with the dereference operator *, say “dereference “ out loud.
4a. Understand the difference between * as declaration, * as dereference unary operator and * as multiple binary operator or do not try to use them! - Same for addressOf & operator. (as well as assignment operator, comparison operator, etc)
- The compiler enforces type safety. Let it do its job! Unless you are dealing directly with hardware or doing low level memory tricks, you should not need to recast something.
|
|
|
|
|
I was writing a lounge entry and the front door got slammed on me.
I tried getting to CP from two different networks so I'm pretty sure it weren't just me.
Ya'all saw that too, right?
I took a snapshot of it.
Here's what I saw[^] and it was instant.
I guess them hamsters is angry.
|
|
|
|
|
Wow, not even the stylized 404 error page. Something really choked. I didn't see anything, FWIW
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
When did you see that ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
I believe it was around 5:45pm Eastern Standard Time on thursday, June 13.
I tried to ping the site to and couldn't get anything -- and it was such a huge disconnect that I thought it looked like a DNS issue.
I remoted to my work computer -- in a geographically different location (another city from me) and on an entirely different ISP and I got the same error from browser : 404.
|
|
|
|
|
I saw that. I guess a 404 is just enough to tell Down Detector and other such sites that "something" is coming back, so they all claimed it was up...
|
|
|
|
|
That's interesting, because for me it was instaneous and quite harsh: I mean I couldn't even ping codeproject.com at that time. It was literally like someone slammed the door on me.
I tried from an entirely different network and got the same thing.
Glad someone else confirmed seeing it to.
|
|
|
|