Redox OS Crash Challenge
21–30 of 82 posts
Re: Redox OS Crash Challenge
#22Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. No cynicism intended, just an observation from what I see around.
I don't see anything in the link that seems to imply that they think Redox OS is going to be crash free? In fact this seems to be the opposite, it looks to me like they're looking for bugs to squash.
I tend to agree. I've shook hands with a lot of people that see Rust as a panacea rather than a mitigation strategy.
Re: Redox OS Crash Challenge
#23Earlier quoted context omitted.
There is (most likely) no perfect isolation. If given no alternatives, a kernel should burn down rather than permitting a privilege escalation. Ideally there is no privilege escalation either. Given bad input the kernel should not fault but sometimes it must.
Imperfect isolation is always treated as a bug. As a kernel developer if you try to argue otherwise you'll get laughed out of the room and/or fired. Hopefully both.
Re: Redox OS Crash Challenge
#24Earlier quoted context omitted.
> Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. > No cynicism intended, just an observation from what I see around. The difference is what happens when a bug is encountered. If it is caught a…
I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callb…
Re: Redox OS Crash Challenge
#25Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. No cynicism intended, just an observation from what I see around.
Sure, but there are also plenty of improvements in Rust that aren't about memory safety. For instance, there's the improved type system over C or C++ (tuples, enums, traits, etc.), related features like pattern-matching on enums and trait-based error handling (the question-mark operator), and a macro system that works at the syntax-tree level and not the source level. All of these mean that you're less likely to write code with logic bugs. This isn't as clearly true as it is that you're less likely to write code with memory safety bugs, and it's harder to either argue or measure empirically, so it's not as commonly claimed as the memory safety. But a lot of stupid bugs in C come from things like forgetting to check error returns, or confusing two things that are both represented as char * , or accessing a resource without proper serialization (which isn't strictly speaking a memory-safety bug), or having side effects in an expression you pass to a macro. Those bugs are harder to write in Rust because there are more readable ways to write the same constructs that don't let you make the same mistakes. You certainly can write safe Rust code that makes the same mistakes, you're just less likely to because it's the more cumbersome way to do it.
Re: Redox OS Crash Challenge
#26Earlier quoted context omitted.
> Rust being advertised as a safe language (which is true) got so much into the user's heads that they think if they write it in Rust it's safe and crash free by default. There are plenty of security/safety bugs that aren't about dereferencing a null or accessing invalid ptr. > No cynicism intended, just an observation from what I see around. The difference is what happens when a bug is encountered. If it is caught a…
I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callb…
Most of Java's security reputation, I think, comes from Java applets, which were a very different model that involved letting malicious actors write the Java code. Java continues to see success in both web application software and Android apps, both of which do not use the applet security model, and it seems that Java's security record there is far better than C or C++ would have been in the same roles.
Re: Redox OS Crash Challenge
#27Earlier quoted context omitted.
I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callb…
Java remains a memory-safe language, though, right? Leaving aside poor deserialization APIs, it's pretty hard to provide malicious input to non-malicious Java source code that takes control over the interpreter. Most of Java's security reputation, I think, comes from Java applets , which were a very different model that involved letting malicious actors write the Java code. Java continues to see success in both web a…
Re: Redox OS Crash Challenge
#28Earlier quoted context omitted.
I remember when all the same arguments were made about Java, which led people to ignore the possibility of memory leakage and privilege escalation, even though both those things are common problems with idiomatic Java. For instance: Swing recommends you register callbacks all over the place, but those cause otherwise dereferenced windows to stay live from the GC’s perspective (this is a general problem with the callb…
> I don’t know Rust well That is one problem and i don't want to attack you. This is something Rust needs to work on! Rust is indeed a relatively hard language to learn and understand and it is not really clear from the beginning nor in the intermediate level if its worth the effort. I can only speak from an empirical standpoint. Time showed – to me and maybe i am the only one – that i have fewer bugs in general, esp…
Re: Redox OS Crash Challenge
#29Earlier quoted context omitted.
Java remains a memory-safe language, though, right? Leaving aside poor deserialization APIs, it's pretty hard to provide malicious input to non-malicious Java source code that takes control over the interpreter. Most of Java's security reputation, I think, comes from Java applets , which were a very different model that involved letting malicious actors write the Java code. Java continues to see success in both web a…
Apache Struts and Equifax might disagree that the handling of exceptions doesn't cause security issues in Java.
I'd argue that this isn't a language-specific issue at all. It happens to be the case that this is implemented using exception handling in Java, by throwing an object containing the request headers, and having it caught by something that parses the provided message for code. But a language without this type of exception handling, like C or Rust, could have the same issue as easily:
if (strcmp(request->content_type, "multipart/form-data") != 0) {
char *error = asprintf("Bad Content-Type header %s", request->content_type);
log(error);
free(error);
return -1;
}
void log(char *message) {
char *ognl = find_valid_ognl(message);
if (ognl)
message = evaluate(ognl);
...
}
I doubt that any language can really, fundamentally, save you from wrongly deciding to evaluate untrusted strings. (I do think that the vulnerability here was made more likely by OGNL being able to instantiate arbitrary Java objects and by not distinguishing TrustedString and UntrustedString types, and a good language can gently steer you away from those mistakes, but it won't be able to completely save you.)Re: Redox OS Crash Challenge
#30Earlier quoted context omitted.
> I don’t know Rust well That is one problem and i don't want to attack you. This is something Rust needs to work on! Rust is indeed a relatively hard language to learn and understand and it is not really clear from the beginning nor in the intermediate level if its worth the effort. I can only speak from an empirical standpoint. Time showed – to me and maybe i am the only one – that i have fewer bugs in general, esp…
Do you recommend any resources to learn rust?