3 ms·
The example with IEF doesn’t make sense. Whether you declare a function private or public doesn’t impact its usability as a gadget. And as I understand it readi
by vlovich123 3y ago
The example with IEF doesn’t make sense. Whether you declare a function private or public doesn’t impact its usability as a gadget. And as I understand it reading up on IEF, the problem with removeDatabase is when it’s exposed as a remotely callable API without any auth check which is a very different problem. Am I misunderstanding what the author is saying?
I think the main problem with the article referenced in the submission is that percentages of vulnerabilities change based on the problem domain. The main threat for web facing services isn’t memory safety but that’s because most web facing services already use memory safe languages like JS, Java/JVM, Python, Ruby, or Go. It’s weird to pick Rust for its memory safety for web services. The reason to pick Rust is because you get C/C++ like performance without the memory safety issues. If you don’t need the perf, all the other languages are better choices because you’ll probably move quicker.
It’s interesting that 20% are still memory vulnerabilities. Assuming this is all the same class of attacks on web services, that means 20% of applications do care about perf and have exploitable memory safety issues. Or the methodology is shoddy and they’re comparing different classes of software. Regardless, the premise of the first article is flawed and rife with statistical analysis problems that paint a misleading picture while the response isn’t infusing me with a lot of confidence on the merits and comes off as unnecessarily fanboish trying to stretch for a reason of “but no rust still makes sense”. 70% of vulnerabilities in Chrome are memory safety. This holds for similar classes of software written in c/C++ (eg Windows). There’s a reason all major c/c++ codebases have started getting grass roots and organizational support to transition away as quickly as possible.
- phicoh 3y agoRust has other advantages as well. For example, a common error when something goes wrong in Python is that a 'None' value ends up somewhere where it shouldn't be. Typically this None has traveled quite a while before some code tried to use it. The richer and stricter type system of Rust makes such errors a lot less likely. And if an error escapes, there usually is a way better indication of the origin of the error than just 'None'.
- pjmlp 3y agoMost of those Rust features over Python, that are commonly referred to, are available in any programming language of ML linage. Caml Light, SML, OCaml, Haskell, F#, Scala, and whatever else is out there. Most of them also come with a REPL, and have multiple toolchains, no need for always be waiting for the compiler.
- phicoh 3y agoIt is very nice that those languages have those features. But it is quite rare that people who are used to C or Python code bases are switching to those languages. In particular a strong point of Rust is that C programmers feel comfortable switching to Rust in way that has not happened with other safe languages.
- pjmlp 3y agoC folks hardly change to anything, at least the hardcore ones, unless forced to by external forces. Python well, it isn't as if Rust is on the same level of developer experience and friendliness. With CPython finally getting a JIT, and Mojo, I don't force that happening long term. In any case, hardly changes the fact of not being Rust specific type system features not available anywhere else.
- phicoh 3y agoThere is a huge amount of C programs and libraries that were written in C because back then it was the best tool for the job. A lot of people are not convinced about C++, but for many things that were written in C, Rust is now a good option. More and more people are asking questions about how C programs avoid memory errors. The easy solution is to switch to Rust for new programs and libraries. Python has the problem that large Python programs are often awkward. There are many reasons for that. And somehow the Python community doesn't seem to be able to solve those issues. Rust is a lot better in that respect.
- 3y ago
- hkolk 3y agoThe second example given (extracting information from a web view) is also weird. The rust code has the exact same flaw as the java code, which is that they do not validate the source. I think the author didn't really understand the underlying problem here. Bounds checking was not the issue with the java (android) code
- vlovich123 3y agoI hate to impune their skills since I don’t know the person and this could just have been a hastily written and poorly thought through article, but for me it brings into question their claims as a cyber security expert with 10 years experience.
- unshavedyak 3y ago> The reason to pick Rust is because you get C/C++ like performance without the memory safety issues. If you don’t need the perf, all the other languages are better choices because you’ll probably move quicker. Lets not forget a competent type system as well. Go/Java are decent, but i'd not even consider dynamic langs these days for any remotely complex project. I just don't believe in the benefits of a dynamic system. I use Rust in areas that otherwise don't require it in part because i prefer the type system.