Exploiting a Go Binary(codearcana.com)
codearcana.com
Exploiting a Go Binary
http://codearcana.com/posts/2013/04/23/exploiting-a-go-binary.html
8 comments
Well, to be fair, if you don't want your binaries exploited, don't write the exploit into them. I can't see a case where this could be used, unless you're letting people execute arbitrary code on your system, in which case you're screwed anyway.
> Well, to be fair, if you don't want your binaries exploited, don't write the exploit into them.
That's a bit naive and not the point of this PoC. The exploit used a bug in the code generator. Normally, guard code would have been generated that would have caught that issue, but it just wasn't, and that's why the exploit worked.
So in theory, every program with that particular programming bug and the missing guard code (due to the code generator bug) is vulnerable.
That's a bit naive and not the point of this PoC. The exploit used a bug in the code generator. Normally, guard code would have been generated that would have caught that issue, but it just wasn't, and that's why the exploit worked.
So in theory, every program with that particular programming bug and the missing guard code (due to the code generator bug) is vulnerable.
Vulnerable to what? As far as I can see, it will crash or corrupt memory when it tries to read/write to it. An actual exploit of this requires intent.
"Never ascribe to malice that which is adequately explained by incompetence"
Imagine a programmer has a shitty day, lacks concentration, and adds code like this to his internet-facing server app:
When handling an HTTP request that comes from the internet, instance.Embedded.address is filled from a GET parameter. Et voila, anyone who can do a GET request can overwrite memory, possibly leading to code execution.
The bug in the code was unintentional, because programmers (like all humans) make mistakes, the HTTP request was intentional (it was done by the attacker), and the exploit worked because of a bug in the code generation.
That's what I meant by vulnerable.
Imagine a programmer has a shitty day, lacks concentration, and adds code like this to his internet-facing server app:
type Embedded struct {
offset [0x400100]byte
address uint32
}
type Struct struct {
*Embedded
bar int
}
var instance Struct
When handling an HTTP request that comes from the internet, instance.Embedded.address is filled from a GET parameter. Et voila, anyone who can do a GET request can overwrite memory, possibly leading to code execution.
The bug in the code was unintentional, because programmers (like all humans) make mistakes, the HTTP request was intentional (it was done by the attacker), and the exploit worked because of a bug in the code generation.
That's what I meant by vulnerable.
Ah, okay. I think this particular exploit falls a bit too far into the "you have to work to make it useful" spectrum (the "offset [0x400100]byte" part), but I see how it might be exploitable, thanks.
It's also worth remembering that a complete exploit can often compose numerous "small" vulnerabilities into the realized breach. As such, it's easy to discount a seemingly hard-to-exploit vulnerability until you see it in action. It may be used in concert with other weaknesses or "widened" by an unforeseen technique.
As a specific example, check out the two-part wrap-up of the Pwnium browser hacking competition[1] [2]. It's a great illustration of chaining weaknesses together to achieve a desired exploit.
[1] http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.h...
[2] http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.h...
As a specific example, check out the two-part wrap-up of the Pwnium browser hacking competition[1] [2]. It's a great illustration of chaining weaknesses together to achieve a desired exploit.
[1] http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.h...
[2] http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.h...
Oh wow, that guy exploited 14 bugs to craft the exploit. That's some work...
> Well, to be fair, if you don't want your binaries exploited, don't write the exploit into them.
That was my point. But without researchers investigating potential exploits, then developers have a harder time writing secure code.
That was my point. But without researchers investigating potential exploits, then developers have a harder time writing secure code.
Hmm, I must be missing something. This isn't a normal binary that can be exploited by a malicious user. This is a binary that exploits the compiler to write to memory to places it shouldn't.
This can only happen if the developer is malicious relatively to the compiler. Since you're the developer, and you're trying to avoid this exploit happening to you, there's no need to worry: Just don't perform the exploit.
It sounds to me like you're saying "we need to have more research so I can avoid exploiting the Go compiler".
This can only happen if the developer is malicious relatively to the compiler. Since you're the developer, and you're trying to avoid this exploit happening to you, there's no need to worry: Just don't perform the exploit.
It sounds to me like you're saying "we need to have more research so I can avoid exploiting the Go compiler".
> Hmm, I must be missing something.
Yes, you missed the part where I said this that was a generalised comment and that I'm aware this specific attack isn't a practical real-world vulnerability.
What you're doing is that typical thing that people do online when they're so busy trying to assert their intellectual superiority that you completely miss the point that was being raised.
Yes, you missed the part where I said this that was a generalised comment and that I'm aware this specific attack isn't a practical real-world vulnerability.
What you're doing is that typical thing that people do online when they're so busy trying to assert their intellectual superiority that you completely miss the point that was being raised.
You don't automatically get ripped without working out.
Same way, software doesn't become secure without being attacked.
It may seem pointless to you, but it makes the ecosystem stronger.
Same way, software doesn't become secure without being attacked.
It may seem pointless to you, but it makes the ecosystem stronger.
[deleted]
To be clear: this is an attack that works if you're compiling and executing malicious Golang code, as if it were Javascript.
Or if you happen to have some fairly odd code in your executable. All that this really needs is really big array of bytes in one struct of your code. While anything that big should be unusual, you never know what crazy stuff people will write.
Odd code like that will crash your executable, and may set up the conditions for some other exploit, but this one requires the code to be very specifically written to maliciously overwrite a function pointer.
What if, instead of a function pointer, an interface happened to be at that address? Given that interfaces are extremely common in Go, it seems plausible to me that many addresses in the heap could contain interfaces (and if they don't, then it may be possible to manipulate an application to create many interfaces so that they do). An attacker could overwrite the vtable pointer to point to attacker-supplied memory, and then an indirect call through the vtable could jump to shellcode.
Sure, that's a plausible vulnerability concept for Go. Someone just has to find a way to do that. :)
If we are writing programs to write to arbitrary memory, wouldn't it be easier to write them in C? :)
int main(int argc, char *argv) {
*((char *)addr_to_write) = val_to_write;
}
It's valid in the sense of, if you tried to use an in-language sandbox to keep people from running arbitrary code on your machine, this would bypass it.
Non-executable heap and stack in Go 1.1 - nice!
Huh, there goes my plan to write a dynamic assembler in Go...
You can still use mmap/equivalent to allocate executable memory and package unsafe to use it; the difference is that the memory allocated normally by the runtime won't be executable.
Or I missed the sarcasm.
Or I missed the sarcasm.
What sarcasm? Well, if I could mmap it, that would be fine, although it would mean that I'd have to manage the memory for the machine code fragments by hand, as opposed to having them as part of GCd values.
I'm really excited to see people working on security in Go. Security by default is supposed to be one of Go's "features" at some level. (The typical example: your first several C programs probably had many buffer overflow vulnerabilities, but it's very likely none of your Go programs ever will.) Still, Go hasn't been very thoroughly tested and security hardened, so I'm hoping to see many more exploits like this discovered and ironed out in the near future.
[deleted]
For some reason, the website is not loading here and Google's cache dates from before the release of the exploit, so the post is hidden.
Anybody has a mirror or some way to access the post?
Anybody has a mirror or some way to access the post?
It was accidently deleted. https://groups.google.com/d/msg/golang-nuts/wZILkqFbbus/j9Wq...
I'm a little confused, does this work on 64-bit binaries too?
Criminalizing those who are only looking to harden the security of public facing infrastructures from those who don't have good intentions doesn't help anyone. And while I'm sure that Geohot and Reece took on this challenge as more of a fun exercise, we've all benefited from the results.
So I look forward to reading more articles where hackers attempt to exploit Go binaries; and subsequently how to avoid my own Go binaries from being exploited the same way.
(i should add, this is a more generalized comment. I'm aware that this specific attack isn't a practical real-world vulnerability)