CWE Top Most Dangerous Software Weaknesses • Hacker News Board

Re: CWE Top Most Dangerous Software Weaknesses

#101

Post by rtev » Thu, Jul 13, 2023, 5:00 PM UTC

gemanor wrote: post #34

I'm really waiting to see all those shift-left startup founders that will craft a new world of developer-oriented products from this list. IMHO, the real way to look at it is how we can influence developers (by choosing the suitable languages, platforms, architectures, etc.) and then measure them after they find the vulns. From the optimistic side, it looks like the safest language to write an app today with is TypeS…

Typescript applications suffer from many of these vulnerabilities. JS apps have a specific class of critical vulnerabilities as well, prototype pollution. If I had to write a web application with security in mind, I personally would pick Python. It’s possible to make mistakes in any language though, and the environment an app is deployed in can independently introduce many vulnerabilities.

Re: CWE Top Most Dangerous Software Weaknesses

#102

Post by tialaramex » Thu, Jul 13, 2023, 5:04 PM UTC

pjmlp wrote: post #53

citrin_ru wrote: post #9

Earlier quoted context omitted.

Is there some authoritative source for what is considered modern C++ and what is old? Most projects I've seen use a wide mix of C++ features of varying age. If you use some C++23 futures it would not make it modern if you still use C++98 features you not supposed to use.

Originally it refers to what was already possible in C++98, when one leaves behind the legacy ways of coding C with a C++ compiler. Started with the publishing of "Modern C++ Design" from Andrei Alexandrescu in 2001. https://en.wikipedia.org/wiki/Modern_C%2B%2B_Design When ISO C++11 came to be, many re-used the term to mean C++11 or higher. Given that many keep updating this to mean more modern versions, a well known…

> programming in C++ as its own language, leave the C ways

I'm with Kate Gregory on the "Stop teaching C" (actually Kate specifically means in order to then teach C++ but I also think it's probably fine to stop teaching C outright)

But whilst Kate is right in terms of pedagogy, as a larger philosophy this is inadequate. As a language C++ is obviously defective and the explanation is almost invariably "Because C" which only makes sense once you appreciate C++ in terms of C.

The built-in array type in C++ is garbage. Why is it garbage? This is a language with all these powerful features, why doesn't its array type leverage any of them? It's because this is actually the array type from C.

OK, maybe just the array type is trash, that's obviously not good, but it's one defect. How about string literals. Oops. C++ does sort of technically have the string literals you actually wanted, but the syntax for them is weird and you need the standard library not the core language... the ones you get for "Some text" are C's constant strings, an array of bytes with an extra zero byte, and well, the array type sucks.

This carries on, the language doesn't provide real tuples, it doesn't provide a real sum type, its built-in types don't believe in methods but user types do, everywhere there are weird choices which are non-sensical except for the reality that it's what C does.

And then at the end of that, the language isn't actually compatible with C. It's close, a lot of stuff works, and more stuff kinda-sorta works enough that you may be surprised when it fails, but there isn't the sort of robust compatibility you might expect given the enormous sacrifices made for this goal.

Re: CWE Top Most Dangerous Software Weaknesses

#103

Post by loup-vaillant » Thu, Jul 13, 2023, 5:08 PM UTC

jerf wrote: post #87

loup-vaillant wrote: post #86

Earlier quoted context omitted.

Safety is nice, but it often costs significant performance. So what you are saying is… if I need performance my only choice is Rust? Don’t get me wrong, I absolutely hate the insanity of Undefined Behaviour™ in C and C++ (my pet peeve being signed integer overflow), and I’m totally behind systematic bounds checking (which with compile time support tends to lie between free and cheap). I’m less sold on ensuring the sa…

"I’m less sold on ensuring the safety of memory shared between threads because I tend to prefer message passing" Memory safety, at least to my eyes, has not traditionally encompassed that as a requirement. I don't consider this a solved problem, in that it has a lot of solutions and consensus about them is still developing. (e.g., I still expect async as it has been implemented in Node & Rust to eventually be conside…

> So my passion is mostly about out-of-bounds access and use-after-free.

Yeah, those are the big ones indeed, and I am willing to take a performance hit to get there. If that’s the only hit I take I’ll still be much better than paying an Electron tax.

I do however still feel some discomfort about use-after-free, because to be honest I just don’t know enough about the relevant use cases, compilation techniques, and runtime checks. So far my only relevant experiences have been GC, RAII, and stack-only. They all solve my problem (or at least I can see how I could write a compiler that would solve each use case for me). But I know those aren’t the only use cases, and I’m not familiar enough with the other allocation patterns (pool, arena…) to have a relevant opinion.

But perhaps I’m just stressing over nothing? The problem is easily stated after all: no object should be accessed after its backing memory has been freed. One way to do that is to make sure the object (and any reference to it) goes out of scope before the backing storage is freed. Which sounds doable enough if the backing storage itself follows a stack discipline…

Hey, I can glimpse here a way to allow allocations and statically guarantee a limit on memory usage (barring input dependant allocation amounts). Perhaps even avoiding fragmentation, which would be terrific for embedded use cases.

Re: CWE Top Most Dangerous Software Weaknesses

#104

Post by sigstoat » Thu, Jul 13, 2023, 5:08 PM UTC

BoppreH wrote: post #83

azornathogron wrote: post #81

Earlier quoted context omitted.

URLs are structured. But when you need to send them across the network or store them on disk or even just send them between different processes on the same machine you need to define what the byte level representation is. I don't see how you can get away from having a defined serialisation format. People try to operate directly on the serialised data using ad-hoc implementations and run into trouble. But I'm not sure…

> I don't see how you can get away from having a defined serialisation format. Yep, that's exactly it. Your TLS certificate is not sent as string, and neither are your TCP packets, nor the images contained in them. Your URLs shouldn't be either, but it's probably too late for that. > People try to operate directly on the serialised data using ad-hoc implementations and run into trouble. That's a whole lot better than…

> > I don't see how you can get away from having a defined serialisation format.

> Yep, that's exactly it. Your TLS certificate is not sent as string, and neither are your TCP packets, nor the images contained in them.

...all of those things mentioned have defined serialization. i expect all of them have had security issues because of problems with deserialization code.

Re: CWE Top Most Dangerous Software Weaknesses

#105

Post by 0xbadcafebee » Thu, Jul 13, 2023, 5:16 PM UTC

matt2000 wrote: post #64

It should be considered a failure of our profession that after all these years the number 1 issue is still out of bounds write, a memory safety issue. In any true engineering profession a failure of this sort would be unacceptable, but in ours it's tolerated and explained away as a necessary byproduct of certain tools. How much personal information has been compromised due to these low standards? How many people put…

In any true engineering profession, we would still be using C, but with big orange safety vests on.

Re: CWE Top Most Dangerous Software Weaknesses

#106

Post by pjmlp » Thu, Jul 13, 2023, 5:19 PM UTC

tialaramex wrote: post #102

pjmlp wrote: post #53

Earlier quoted context omitted.

Originally it refers to what was already possible in C++98, when one leaves behind the legacy ways of coding C with a C++ compiler. Started with the publishing of "Modern C++ Design" from Andrei Alexandrescu in 2001. https://en.wikipedia.org/wiki/Modern_C%2B%2B_Design When ISO C++11 came to be, many re-used the term to mean C++11 or higher. Given that many keep updating this to mean more modern versions, a well known…

> programming in C++ as its own language, leave the C ways I'm with Kate Gregory on the "Stop teaching C" (actually Kate specifically means in order to then teach C++ but I also think it's probably fine to stop teaching C outright) But whilst Kate is right in terms of pedagogy, as a larger philosophy this is inadequate. As a language C++ is obviously defective and the explanation is almost invariably "Because C" whic…

I mostly agree with you.

The issue is how "worse is better" culture tends to win, and if the option is between C and C++ for a given scenario, then I definitely take C++.

However if the option pool is widened to more alternatives, then yeah, there should be a sound reason for still pick them for greenfield development, e.g. CUDA, a language toolchain based on LLVM,...

Re: CWE Top Most Dangerous Software Weaknesses

#107

Post by BoppreH » Thu, Jul 13, 2023, 5:31 PM UTC

taeric wrote: post #97

BoppreH wrote: post #83

Earlier quoted context omitted.

> I don't see how you can get away from having a defined serialisation format. Yep, that's exactly it. Your TLS certificate is not sent as string, and neither are your TCP packets, nor the images contained in them. Your URLs shouldn't be either, but it's probably too late for that. > People try to operate directly on the serialised data using ad-hoc implementations and run into trouble. That's a whole lot better than…

Your certificate isn't entered by hand, though? That is, it is easy to see that the reason we have URLs sent as strings, is that we collect them from the user. And it makes perfect sense that we would collect strings of characters from users.

How many URLs, as a percent of all browser navigation, do you think are typed by hand? And I don't mean "news.ycombinator.com", I mean the full URL, like "https://news.ycombinator.com/news".

And in those rare cases, of course you can collect strings from the user. But then they have to be parsed, and that's what should be on the wire. IP addresses are also sometimes entered by hand, but we don't send those strings in TCP packets.

Re: CWE Top Most Dangerous Software Weaknesses

#108

Post by fulafel » Thu, Jul 13, 2023, 5:40 PM UTC

amelius wrote: post #40

Is anyone using Valgrind even anymore these days? I've noticed that using Valgrind on Python systems is almost impossible because most modules have not been built with Valgrind in mind and thus you get swamped in noise. I suppose the same is true for any large system that uses many different third party libraries.

It is useful but quite limited by itself for security bugs - it's dynamic instrumentation so you'd need to test with the input triggering the vulnerability. (But useful in combination with fuzzing, similarly to the compiler sanitizer options)

Re: CWE Top Most Dangerous Software Weaknesses

#109

Post by chefandy » Thu, Jul 13, 2023, 5:42 PM UTC

UncleMeat wrote: post #68

chefandy wrote: post #42

Earlier quoted context omitted.

Those two things aren't mutually exclusive. I'll bet a non-trivial number of XSS and SQL injection vulnerabilities came from people disabling input and output sanitation on solid frameworks and libraries because they didn't know why they shouldn't. Tools won't solve all of your problems-- you need knowledge, diligence, and tools that make doing the right thing easy.

> I'll bet a non-trivial number of XSS and SQL injection vulnerabilities came from people disabling input and output sanitation on solid frameworks and libraries because they didn't know why they shouldn't. I will take this bet.

Searching Google for disabled sanitation "vulnerability", the first two hits are articles admonishing developers to not do it, and the third is a CVE, CVE-2023-1159, from a month ago that affects WordPress installations on which the developer disabled unfiltered_html, which is it's built-in sanitation functionality.

Re: CWE Top Most Dangerous Software Weaknesses

#110

Post by pjmlp » Thu, Jul 13, 2023, 5:42 PM UTC

j16sdiz wrote: post #99

pjmlp wrote: post #50

Earlier quoted context omitted.

You mean tecnhology like bounds checking, invented during the 1950's decade, with the creation of Fortran, Lisp and Algol, and every other language derived from them, with exception of C, C++ and Objective-C?

with bounds checking, out of range index still trigger exception or runtime error. Many of them results in DoS.

Much better than silent data corruption.

Then there is the whole issue of making it more interesting to look elsewhere instead.

When a door is locked I can still break in by throwing a rock to the window, yet most people do lock the door nonetheless, while most thieves only bother to break the window if there is anything actually valuable in doing so.