Yes, but Go is not a scripting language and the playground is sandboxed for a good reason. Go was not designed as javascript to be safely run even with untrusted sources. Go assumes source code is safe and trusted like most languages do.
-
-
The scripting doesn't need to be in the Go code to accomplish the same thing, and as I said, that sounds a lot like many commonly deployed environments.
1 reply 0 retweets 1 like -
i.e. it can be JavaScript or Lua scripting closely tied to Go code, such as a web browser, custom map / mod scripting for a game engine, etc. There are a lot of cases where an attacker has scripting capabilities. Remote access to a service can also provide similar capabilities.
2 replies 0 retweets 0 likes -
It's definitely way harder to do an exploit like this without either direct remote connections to a service or even better local scripting. Still, I'm not really surprised anymore when people exploit something like a 1 byte null overflow without scripting or an active connection.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @pcwalton
This specific exploit still requires the race detector to be disabled, and the other ones we saw require arbitrary *go* to be compiled in the executable.
1 reply 0 retweets 0 likes -
Replying to @empijei @DanielMicay
The issue here is that the language could have been designed to avoid such problems. Interfaces could have been double-boxed and slices could have been (ptr, start, end) with start/end untrusted by the implementation.
1 reply 0 retweets 0 likes -
Replying to @pcwalton @DanielMicay
How much more complicated and slow would the language need to be to address the threat model of untrusted code being compiled inside a trusted unit? Also, why do you mention slices? Go has slices implemented as {ptr, len, cap} and performs boundary checks.
1 reply 0 retweets 0 likes -
Replying to @empijei @DanielMicay
It doesn’t need to be complicated and slow at all. Java and C# designed interfaces without those problems (much earlier than Go did). The problem with slices is that Go trusts the length. So a race could overwrite ptr to point to a smaller alloc, allowing for OOB R/W.
2 replies 0 retweets 0 likes -
Replying to @pcwalton @DanielMicay
But yet again, that would be a race condition in your code and that could corrupt other parts of your logic. If you have a race condition at any level you lose soundness and you can't create a race free language.
1 reply 0 retweets 0 likes -
I think there are many things a language cannot take care of and there is a limited amount of time you can invest at any time. It is all about tradeoffs, Go decided that races would have been possible and decided to not invest in limiting their effects.
2 replies 0 retweets 0 likes
It’s not about whether races are possible. It’s about whether they lead to violations of type/memory safety. In Java and .NET, races can lead to logic bugs, but cannot violate type/memory safety. In Go, they can lead to both logic bugs and type/memory safety violations.
-
-
Replying to @pcwalton @DanielMicay
I understand and respect your opinion.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.