|
Wordle 1,091 4/6*
🟨⬜⬜⬜⬜
⬜🟨🟨⬜🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 1,091 4/6
🟨⬜⬜⬜🟨
⬜🟨⬜🟨🟨
⬜🟨⬜🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
⬜⬜🟨⬜⬜
⬜⬜⬜🟨⬜
🟩🟩🟩🟩🟩
Good but lucky guess
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
|
|
|
|
|
Wordle 1,091 4/6*
🟨🟨🟨⬜⬜
🟨🟩🟨⬜⬜
🟨🟩⬜🟨⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
|
|
|
|
|
Wordle 1,091 5/6
🟨🟨⬛⬛⬛
⬛🟨🟨⬛⬛
⬛🟩⬛🟩⬛
⬛🟩🟩🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,091 3/6
⬛⬛🟨⬛🟩
🟨🟨⬛⬛🟩
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
Wordle 1,091 4/6*
🟨🟨⬛⬛⬛
⬛🟩⬛🟨⬛
⬛🟩⬛🟨⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
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.
|
|
|
|