~Alex Reece
Well, assuming that there are no memory corruption bugs in the Go runtime itself (and the assumption you were already making that Go binaries are never linked against C libraries).I would like to point out that the vulnerable program (webapp) is exploitable on a 64 bit machine almost exclusively because the go runtime eschews the protections that are considered crucial for C programs. The vulnerability introduced by the C code isn't exploitable without the weak go runtime (ALSR, NX, and libc randomization pretty much eliminate any surface for exploiting the C parts of the program).
"Lastly, the behavior I performed in cgo could have trivially been perfomed in pure Go."
Quoting your last mail list post:
"I acknowledge that it is hard (perhaps impossible) to find vulnerabilities in pure Go binaries -one would probably have to find a bug in the Go runtime itself. But that's just it -by eschewing common protections, Go is widening the class of bugs (in its runtime) that could turn into viable exploits."
Please let me know which of them should be considered your opinion. I think they pretty much contradict each other.
> "Lastly, the behavior I performed in cgo could have trivially been perfomed in pure Go."
On Wednesday, 9 May 2012 16:52:38 UTC+1, Kyle Lemons wrote:On Wed, May 9, 2012 at 2:20 AM, David Symonds <dsym...@golang.org> wrote:The two quotes you posted are consistent.
The first is making a statement about the particular implementations
of the Go tools. They were written by people (well, as people-like as
Ken and Russ are), and those people can make mistakes. Those mistakes
can lead to programs behaving in a way that the language spec does not
permit.
The second is making a statement about Go (the language), and that, by
design, typical buffer overflows are impossible because the runtime
does bounds checking, as compared to C where, by design, there is no
bounds checking done. Thus a programmer error in C can lead to a
serious security problem (namely, arbitrary memory access), whereas in
Go it will only lead to the program panicking. (bounds checking is an
example)To expand a bit: Go is not necessarily a more secure language than any other; just because you can't overflow a buffer doesn't mean you can't induce a race condition to get around some security check or DoS a server or inject SQL or perform XSS or any number of other attacks. It strikes me as a more fruitful venture to work on developing easy ways to mitigate these hard security problems than to work on hardening the Go runtime against, for instance, exploits leveraging C code included with cgo or mistakes made with "unsafe".Okay, Interesting posts, but perhaps if no one can agree what the correct security stance of the language should be or even if a runtime can ever be secure, etc etc etc etc??????
All these C botches, ASR, stack protectors , and the other nonsense, it kinda works, but it's all patches on patches because you can't change direction… it C…love it or hate it!, you stuck with all it's short comings (assembly for newbies as we call it).golang is/was a chance to rethink a system language , and architecturally 'code out' these kind of security problems, rather than a band aid there, and a patch there.
perhaps a simple compiler warning when you link to a potentially security prone language, thus if f you do link to memory exploitable language , golang can always give A WARNING!!!!….
if things do blow up in your face….'well we did WARN you' ;-) then we can blame the explosion on you. neat huh!ho ho ho.I do believe that there's a place for a golang 'secure coding manual', within go's documentation, there are ways to code securely and it's disappointing that most coders learn secure coding last…..
when it should be touched on from day one….. , okay the runtime may have solved a number of issue where C can be dangerous, but there's more to secure coding than just relying on what the runtime enforces. I've seen supposedly 'secure' code in many 'safe' languages that would be exploited just as east as input driven, data dependent, memory execution exploits :-)There's an awful lot research been done on why programs fail, and fail in such a way that can be exploited in some way. It would be great if golang could be as pragmatic about security than it is about language design, and try and enforce some this research either through changes in the language, code quality, or policy enforcement… some times it's just a set of 'best practices' for coders to follow can suffice!! :-)
Secure code, is usually better running code, better optimised code, and better understood code and lot less Klocs of crap…. and that's why coders who can do it are very expensive … :-)
at the end of the day, your still running golang on top of millions of lines of C anyway (the kernel + OS + libs) …… I look forward to the golang kernel and OS soon :-)
Right golang dragons, gear up your smoking nostrils, and prepare to douse me buckets of flames!!…. arrrrggggghhh been nice knowing you.Lee
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Secure code, is usually better running code, better optimised code, and better understood code and lot less Klocs of crap…. and that's why coders who can do it are very expensive … :-)
It's heating up in here, flame proof suit zipped up… From both post I see , security is hard, lets give up.
You'll never be secure … oh dear..
Lets not think about security..is that even ethical? should you be allowed to write production code for say gmail, if your not at least 'thinking' about how to makeyour code more secure?
If you writing a few games at home, them perhaps security is not a big thing for you, but go is a systems language, I've seen my fair few of 'systems', they are big, sprawling, contain very important and valuable data.
So how can a system language not have security at least in mind? I wonder what the core team think of this? Does golang have a security officer? What steps are being made to ensure the runtime is bug free? Can't we help developer by at least warning them if they are going to do things are could be unsafe.
I'm not sure if you two are part of the core development go team, but i certainly hope that the core developers think about this stuff.
kyle/minux was are you use cases for deploying go into production? Would you be interested in writing secure code in the future? Have you written secure code in the past? Security is really about context , i'm trying to gauge where you fit in to this.
Why did we goto the moon?Not because it easy , because it was hard. (or did they fake the moon landings, tinfoil hat current in place).
On Mon, Apr 30, 2012 at 21:51, David Leimbach <lei...@gmail.com> wrote:
> I was just playing with pointers yesterday, trying to understand a memory
> issue I thought I was having (me not remembering the memory model mostly).
>
> I came to the conclusion that pointers were showing up at very much the same
> memory addresses each time, and that perhaps randomizing this would be a
> good idea.
Address space randomization is an OS-level workaround for a
language-level problem, namely that simple C programs tend to be full
of exploitable buffer overflows. Go fixes this at the language level,
with bounds-checked arrays and slices and no dangling pointers, which
makes the OS-level workaround much less important. In return, we
receive the incredible debuggability of deterministic address space
layout. I would not give that up lightly.
Russ