6 ms·

“You have full control of your data, with no concerns about security” This makes me a little worried about non-memory management security bugs. Rust is definit

by jupp0r 4y ago

“You have full control of your data, with no concerns about security” This makes me a little worried about non-memory management security bugs. Rust is definitely helpful in eliminating one major category of bugs, but the belief that this is sufficient for users to not have to worry about security is misguided.

lagrange77 4y ago
Ok fair point, but if run it additionally on a Mac, you should be completely safe.
- etskinner 4y ago
  What does running it on Mac have to do with avoiding non-memory-safety bugs?
  - hkwerf 4y ago
    That may have been sarcasm.
    - lagrange77 4y ago
      It was. There has been a time, when many people thought Macs were inherently safe systems, just because there was way less malware for it, than for windows.
      - deleted 4y ago
        [deleted]
moldavi 4y ago
In fact, in the pursuit of eliminating memory-safety and security bugs, Rust can sometimes makes some privacy bugs more likely. For example, in GC'd/RC'd languages, if we have several UserAccount instances and a bunch of long-running operations on them, any particular long-running operation will just hold a reference to the UserAccount itself and modify it at will without any confusion. In Rust, the borrow checker often doesn't let us hold a reference from a long-running operation in practice, so we work around it by putting all UserAccount instances into a Vec<UserAccount>, and have our long-running operations refer to it via an index. However, we might erase and re-use a spot in that Vec, meaning the index now refers to some other UserAccount. If the operation uses that "dangling index", it can lead to leaking sensitive data to the wrong users, or data loss. When using Rust, one has to use discipline to avoid this bug: use IDs into a hash map, or generational indices, or Rc<RefCell<T>>. Each has its own performance hit, but that hit can be worth it to prevent privacy bugs. In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data. I'm not saying we should always use GC'd or RC'd languages for privacy-sensitive purposes, but one should be aware of the particular shortcomings of their tools and have proper practices and oversight in place to mitigate them.
- deleted 4y ago
  [deleted]
- estebank 4y ago
  > When using Rust, one has to use discipline to avoid this bug: use IDs into a hash map, or generational indices, or Rc<RefCell<T>>. Each has its own performance hit, but that hit can be worth it to prevent privacy bugs. The perf hit of generational indices/arenas is minimal, and the cost of Rc<RefCell<T>> is still lower than complex GCs without JIT. > In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data. I've seen that exact bug in systems written in all kinds of languages. And for what is worth, keeping a Vec<UserAccount> in memory only works on single instance services, anything beyond that and you'd have to deal with cache invalidation as well.
- ComputerGuru 4y ago
  Storing the index of an item in a vector in an actual application (vs in some tightly bounded api of a small, purpose-built library used by said application) is highly non-idiomatic and would emit noticeable stink in any code review. It’s just too hard to remember to update all indices after removing an entry. I’ve seen this mistake made in C, C++, rust, C#, JS, and Python code bases and it is usually someone that hasn’t been around long enough to understand the implicit technical debt in certain approaches that would suggest such a thing, regardless of language. The most obvious/naive solution along the lines you spelled out (in rust but really for any language) would be a hash map of ids/values, otherwise Rc and maybe some weak references.
  - moldavi 4y ago
    That's why I said one should have the discipline and practices in place to avoid this bug. I think we can do better than saying that indexes into Vecs are "non-idiomatic" in applications... such advice could remove much of Rust's performance advantage, and make folks wonder why we're not just using GC. Perhaps we could instead say that if one finds themselves reusing slots in a Vec, they should instead use generational indices, hash maps, or Rc<RefCell<T>>, depending on their use case and what kind of performance overhead they'd prefer.
maldev 4y ago
Rust is really bad for security. It puts debug strings and full source file paths inside binaries. It's been a bug for over 5 years that's been reported and there's been no progress. Nobody talks about this wild dataleakage. Also leaks usernames on computers and such. This can lead to ALOT of forensics information and be used by authoritarian nations to find and arrest people for making software. I really don't think any rust application can meet some compliance requirements for certain sectors due to this either. But the developers and communities just wash this and other real issues under the rug.
- eska 4y ago
  Did you call “strip” on the final executable? It is now also possible to specify “no debug info” for the release build in the build config.
  - maldev 4y ago
    Yes, you can verify that it doesn't work by looking at godbolt. Here's a very simple example. https://godbolt.org/z/sqW8xcGEc https://godbolt.org/z/sqW8xcGEc . For some reason everyone seems to suggest that when it's a currently open (For the last 5 years) issue on their github of it not working. Using a third party tool and binary patching is not an appropriate measure of securing a binary in the case of the linux strip util.
    - estebank 4y ago
      The default hasn't been changed yet (and if you look at the tickets there's ongoing conversation), but you can use `--remap-path-prefix` today if you need it. https://godbolt.org/z/zTh36c6Pz https://godbolt.org/z/zTh36c6Pz
      - maldev 4y ago
        That's good for the path. But there's still concern with the filenames being there, along with being mapped to specific functions. Filenames can be relatively unique and makes signature matching extremely easy. So it can still cause issues to people who have to worry about authoritarian regimes, as it's not out of the realm of this being enough evidence to arrest someone for having all the filenames. It also affects obfuscation and licensing in commercial products. As you can map most functions to a file based off of this handling and find code to target. It's even worse, as if you were to strip the string and replace them all with giberish, it's still possible to map each file by xref's and find related functions. With how signature are in RE tools, you can automatically detect crypto functions and then map that every other function in the file, finding licensing checks easily. The compiler should really respect privacy, and while the ticket is ongoing, it's been ongoing for 6 years and they just made it a bug last year, with no progress. This is a huge blocker for businesses or privacy related domains which instantly makes the language a no-touch.
geophertz 4y ago
I don't think that statement refers to rust at all. It's just referring to the fact the software is open source and the user's data doesn't go through a third-party

by jupp0r 4y ago

lagrange77 4y ago

Ok fair point, but if run it additionally on a Mac, you should be completely safe.

etskinner 4y ago
What does running it on Mac have to do with avoiding non-memory-safety bugs?
- hkwerf 4y ago
  That may have been sarcasm.
  - lagrange77 4y ago
    It was. There has been a time, when many people thought Macs were inherently safe systems, just because there was way less malware for it, than for windows.
    - deleted 4y ago
      [deleted]

moldavi 4y ago

In fact, in the pursuit of eliminating memory-safety and security bugs, Rust can sometimes makes some privacy bugs more likely. For example, in GC'd/RC'd languages, if we have several UserAccount instances and a bunch of long-running operations on them, any particular long-running operation will just hold a reference to the UserAccount itself and modify it at will without any confusion. In Rust, the borrow checker often doesn't let us hold a reference from a long-running operation in practice, so we work around it by putting all UserAccount instances into a Vec<UserAccount>, and have our long-running operations refer to it via an index. However, we might erase and re-use a spot in that Vec, meaning the index now refers to some other UserAccount. If the operation uses that "dangling index", it can lead to leaking sensitive data to the wrong users, or data loss. When using Rust, one has to use discipline to avoid this bug: use IDs into a hash map, or generational indices, or Rc<RefCell<T>>. Each has its own performance hit, but that hit can be worth it to prevent privacy bugs. In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data. I'm not saying we should always use GC'd or RC'd languages for privacy-sensitive purposes, but one should be aware of the particular shortcomings of their tools and have proper practices and oversight in place to mitigate them.

deleted 4y ago
[deleted]
estebank 4y ago
> When using Rust, one has to use discipline to avoid this bug: use IDs into a hash map, or generational indices, or Rc<RefCell<T>>. Each has its own performance hit, but that hit can be worth it to prevent privacy bugs. The perf hit of generational indices/arenas is minimal, and the cost of Rc<RefCell<T>> is still lower than complex GCs without JIT. > In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data. I've seen that exact bug in systems written in all kinds of languages. And for what is worth, keeping a Vec<UserAccount> in memory only works on single instance services, anything beyond that and you'd have to deal with cache invalidation as well.
ComputerGuru 4y ago
Storing the index of an item in a vector in an actual application (vs in some tightly bounded api of a small, purpose-built library used by said application) is highly non-idiomatic and would emit noticeable stink in any code review. It’s just too hard to remember to update all indices after removing an entry. I’ve seen this mistake made in C, C++, rust, C#, JS, and Python code bases and it is usually someone that hasn’t been around long enough to understand the implicit technical debt in certain approaches that would suggest such a thing, regardless of language. The most obvious/naive solution along the lines you spelled out (in rust but really for any language) would be a hash map of ids/values, otherwise Rc and maybe some weak references.
- moldavi 4y ago
  That's why I said one should have the discipline and practices in place to avoid this bug. I think we can do better than saying that indexes into Vecs are "non-idiomatic" in applications... such advice could remove much of Rust's performance advantage, and make folks wonder why we're not just using GC. Perhaps we could instead say that if one finds themselves reusing slots in a Vec, they should instead use generational indices, hash maps, or Rc<RefCell<T>>, depending on their use case and what kind of performance overhead they'd prefer.

maldev 4y ago

Rust is really bad for security. It puts debug strings and full source file paths inside binaries. It's been a bug for over 5 years that's been reported and there's been no progress. Nobody talks about this wild dataleakage. Also leaks usernames on computers and such. This can lead to ALOT of forensics information and be used by authoritarian nations to find and arrest people for making software. I really don't think any rust application can meet some compliance requirements for certain sectors due to this either. But the developers and communities just wash this and other real issues under the rug.

eska 4y ago
Did you call “strip” on the final executable? It is now also possible to specify “no debug info” for the release build in the build config.
- maldev 4y ago
  Yes, you can verify that it doesn't work by looking at godbolt. Here's a very simple example. https://godbolt.org/z/sqW8xcGEc https://godbolt.org/z/sqW8xcGEc . For some reason everyone seems to suggest that when it's a currently open (For the last 5 years) issue on their github of it not working. Using a third party tool and binary patching is not an appropriate measure of securing a binary in the case of the linux strip util.
  - estebank 4y ago
    The default hasn't been changed yet (and if you look at the tickets there's ongoing conversation), but you can use `--remap-path-prefix` today if you need it. https://godbolt.org/z/zTh36c6Pz https://godbolt.org/z/zTh36c6Pz
    - maldev 4y ago
      That's good for the path. But there's still concern with the filenames being there, along with being mapped to specific functions. Filenames can be relatively unique and makes signature matching extremely easy. So it can still cause issues to people who have to worry about authoritarian regimes, as it's not out of the realm of this being enough evidence to arrest someone for having all the filenames. It also affects obfuscation and licensing in commercial products. As you can map most functions to a file based off of this handling and find code to target. It's even worse, as if you were to strip the string and replace them all with giberish, it's still possible to map each file by xref's and find related functions. With how signature are in RE tools, you can automatically detect crypto functions and then map that every other function in the file, finding licensing checks easily. The compiler should really respect privacy, and while the ticket is ongoing, it's been ongoing for 6 years and they just made it a bug last year, with no progress. This is a huge blocker for businesses or privacy related domains which instantly makes the language a no-touch.

geophertz 4y ago

I don't think that statement refers to rust at all. It's just referring to the fact the software is open source and the user's data doesn't go through a third-party