Comment by Smaug123

Comment by Smaug123 10 days ago

I don't even use Golang, I maybe read two Golang repos a year, I find these errors in almost every repo I look at (probably because of the selection effect: I only look at the code for tools I find bugs in). One of them I remember was a critical vulnerability of exactly this form, so :shrug: Perhaps I'm just grotesquely unlucky in the Golang projects I see, but that makes maybe 10% of the Golang error-handling bugs I've found to be security bugs.

tptacek 10 days ago

Sounds memorable. Say more about this critical vulnerability?

Reply View 19 replies

Smaug123 10 days ago

I'll gesture at it. It's not an open source tool, so I can't point at the code (and in fact I just checked and I don't have perms to see the Jira ticket I caused to be raised!), and I am wary of describing security bugs in company-internal code. But in general terms it was a service that attempted to check whether a request was allowed, and it ignored errors from that check. (I just searched history for a bit to find the error in the absence of any actual details about it, but it was a while ago and I failed.) Sorry this is not a very satisfying answer.

Reply View | 18 replies
- [removed] 10 days ago
  
  [deleted]
  
  Reply View | 0 replies
- foldr 9 days ago
  
  Any language where errors are returned as values will allow you to ignore errors (if you don’t have proper linting set up, and unless it has something fancy like linear types). I’ve even seen a similar error in Haskell code, where someone called an isLoggedIn function inside a monad with the expectation that it would short-circuit evaluation, whereas in fact it just retuned a Bool.
  
  Reply View | 13 replies
  
  thinkharderdev 9 days ago
  
  Very true, but I do think there is an issue in the margin about how easy it is to ignore errors. For example, in Java you might have something like
``` void checkPermissions() throws AuthException ```
so you have to actively ignore errors by catching the exception. Likewise in Rust you can do
``` fn check_permissions() -> Result<(),AuthError> ```
  In that case you can just use the `?` operator to short-circuit (and clippy will warn you if your forget to do that).
  In other words, while language design can't fully prevent you from ignoring precondition checks, it can make it harder to forget or even force you to actively ignore precondition failures
  
  Reply View | 12 replies
- [removed] 10 days ago
  
  [deleted]
  
  Reply View | 0 replies
- goodlinks 9 days ago
  
  Isnt this the same as any language though.. check if have permission then ignore the result seems like something that the language cannot protect you from?
  
  Reply View | 1 reply
  
  Smaug123 9 days ago
  
  I mean, Golang has an unused variables compile error, which presumably is trying to do precisely this. It's like they got so close to forcing the user to acknowledge the possibility of errors, and then stopped just before the end!
  
  Reply View | 0 replies