Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security advisory for crates.io

users.rust-lang.org

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Security advisory for crates.io

#11

Post by steveklabnik »

cesarb wrote: post #8
steveklabnik wrote: post #7

Earlier quoted context omitted.

If you subscribe to rustlang-security-announcements@googlegroups.com , you'll get emails. No JS required there. (With Javascript disabled, that page still renders, so I'm not sure why it doesn't show for you.)

It might depend on how the Javascript is being blocked. I use uBlock Origin advanced mode to selectively block Javascript (I imagine uMatrix is similar), and always have to whitelist discourse's CDN. The difference is probably that selective blockers like uBlock/uMatrix don't show elements, while globaly disabling Javascript does, and discourse might be relying on the noscript element (on mobile right now, so I can't…

Possibly, yeah; I went to about:config to disable it and triple check before I made my comment. Maybe it interacts differently with various plugins.

Re: Security advisory for crates.io

#12

Post by steveklabnik »

tetraodonpuffer wrote: post #6

the response time of the rust team was extremely quick, great job! 2017-09-13 @ 19:19 - Justin sends mail to security@rust-lang.org about this 2017-09-13 @ 19:28 - response sent to Justin acknowledging the vulnerability 2017-09-13 @ 21:14 - a patch to crates.io was finished, all current tarballs verified not-malicious

All kudos to Alex and Carol on this one; by the time I had seen the email, the fix was already being tested!

Re: Security advisory for crates.io

#13

Post by otakucode »

tetromino_ wrote: post #10
steveklabnik wrote: post #2

As always: there are no silver bullets. Static typing, nor Rust, can save you from all bugs. If you follow the link to the security announcement list, you can see the one other advisory we've had since 1.0 as well.

Rust gives us memory safety. But I wonder if somebody is working on a language which syntactically enforces safe filesystem access, and relegates anything resembling the POSIX API to unsafe{}?..

'Safe' filesystem access? Honest question, but what would that look like? How is my software going to know that inserting 'no' into my mail file or overwriting a file or creating a new one was a 'bad' operation? Aside from adopting an immutable content-addressable storage system (something like Camlistore) I'm not sure how filesystem access could ever approach 'safe.' But, I haven't given it a great deal of thought or reading, so you might be referring to something entirely different or have better ideas.

Re: Security advisory for crates.io

#14

Post by tetromino_ »

otakucode wrote: post #13
tetromino_ wrote: post #10

Earlier quoted context omitted.

Rust gives us memory safety. But I wonder if somebody is working on a language which syntactically enforces safe filesystem access, and relegates anything resembling the POSIX API to unsafe{}?..

'Safe' filesystem access? Honest question, but what would that look like? How is my software going to know that inserting 'no' into my mail file or overwriting a file or creating a new one was a 'bad' operation? Aside from adopting an immutable content-addressable storage system (something like Camlistore) I'm not sure how filesystem access could ever approach 'safe.' But, I haven't given it a great deal of thought o…

For example, the hypothetical language could require you to declare that a block of code is allowed to write only within a certain filesystem path (or list of paths). Attempts to escape from the path prefix - e.g. using /../ - would be caught by the compiler for static paths; and non-static strings representing paths would be required by the language's type system to be passed through a specific validator before they can be used for filesystem access.

Re: Security advisory for crates.io

#15

Post by naasking »

otakucode wrote: post #13
tetromino_ wrote: post #10

Earlier quoted context omitted.

Rust gives us memory safety. But I wonder if somebody is working on a language which syntactically enforces safe filesystem access, and relegates anything resembling the POSIX API to unsafe{}?..

'Safe' filesystem access? Honest question, but what would that look like? How is my software going to know that inserting 'no' into my mail file or overwriting a file or creating a new one was a 'bad' operation? Aside from adopting an immutable content-addressable storage system (something like Camlistore) I'm not sure how filesystem access could ever approach 'safe.' But, I haven't given it a great deal of thought o…

> 'Safe' filesystem access? Honest question, but what would that look like?

Safety is a spectrum. Consider a file system API that didn't let you obtain access to a parent directory, and didn't let you ambiently designate any path you like via an unchecked string and turn said string into a real handle to whatever lies at that path. Your program starts with a handle to what it's allowed to reference.

Any subroutine you passed a directory handle then couldn't obtain anything outside of that path (effectively a jail), and any subroutine that wasn't passed any handles can't read or modify the file system at all.

Re: Security advisory for crates.io

#16

Post by kam »

tetromino_ wrote: post #10
steveklabnik wrote: post #2

As always: there are no silver bullets. Static typing, nor Rust, can save you from all bugs. If you follow the link to the security announcement list, you can see the one other advisory we've had since 1.0 as well.

Rust gives us memory safety. But I wonder if somebody is working on a language which syntactically enforces safe filesystem access, and relegates anything resembling the POSIX API to unsafe{}?..

It's a syscall interface, not a language, but CloudABI combines concepts from POSIX and capability-based security.

https://github.com/NuxiNL/cloudlibc/blob/master/README.md

Re: Security advisory for crates.io

#17

Post by wahern »

tetromino_ wrote: post #14
otakucode wrote: post #13

Earlier quoted context omitted.

'Safe' filesystem access? Honest question, but what would that look like? How is my software going to know that inserting 'no' into my mail file or overwriting a file or creating a new one was a 'bad' operation? Aside from adopting an immutable content-addressable storage system (something like Camlistore) I'm not sure how filesystem access could ever approach 'safe.' But, I haven't given it a great deal of thought o…

For example, the hypothetical language could require you to declare that a block of code is allowed to write only within a certain filesystem path (or list of paths). Attempts to escape from the path prefix - e.g. using /../ - would be caught by the compiler for static paths; and non-static strings representing paths would be required by the language's type system to be passed through a specific validator before they…

Symlinks mean that you cannot simply validate the path string. You need to iteratively walk the path using openat(2) to avoid TOCTTOU bugs. But iteratively walking the tree with openat makes it tricky to tell if you've left the containing directory, especially if you dereference symlinks (disallowing them would be easier). This sort of thing is better handled in the kernel; or rather, whatever code is resolving and creating the resource handle in the first instance.

Unix chroot provides precisely the behavior desired here; unfortunately it requires root privileges.

Capsicum introduced the O_BENEATH flag to the openat(2) system call. openat(somedirfd, path, O_BENEATH) will fail if the path references a file above somedirfd. Unfortunately I don't think it has yet made it into Linux or FreeBSD, no doubt because the semantics are trickier than you'd think (there are very good reasons why chroot is limited to root, so you can't simply reuse the chroot infrastructure). See https://lwn.net/Articles/619146/ and https://reviews.freebsd.org/D2808 and http://capsicum-linux.org/

Post reply on HN