Is Go a security malware risk?

[Gopher-Insane]

Hi

So our security team has raised a concern with Go and malware. The link that was sent to me was https://securityboulevard.com/2021/09/behavior-based-detection-can-stop-exotic-malware/. 
I reached out to Bill Kennedy on Twitter who disagreed that Go was a problem. Said it was worth posting here to hear people's thoughts. 

Thanks!

[Axel Wagner]

On Mon, Aug 22, 2022 at 3:31 PM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

So our security team has raised a concern with Go and malware. The link that was sent to me was https://securityboulevard.com/2021/09/behavior-based-detection-can-stop-exotic-malware/. 

ISTM that the argument is that the existence of Go and other languages makes the ecosystem less secure, as it makes it harder to write malware detection software.

I'd respond:

1. If that's so, all a malware author would have to do is do the same thing Go does in C (or whatever) and be safe from detection

2. I don't know if the overall tradeoff is correct. It seems doubtful to me, that the benefit for security from having memory safe languages which are easy to use is smaller than the detriment from harder malware detection. In particular, as the actual benefits from malware detection are, I think, relatively small.

3. Even if all of that's the case, it doesn't seem to have an actionable takeaway. The argument only concerns unknown binaries, so it doesn't actually affect usage by a company - any such usage will produce known binaries. And Go and all these other languages won't stop existing, so you don't have any influence over whether malware authors use it and send you unknown binaries.

I don't really understand the argument made here. It certainly isn't in any sense an argument "against Go". As far as I can tell, it's really only relevant to authors of malware and malware detection software as something to take into account.

 

I reached out to Bill Kennedy on Twitter who disagreed that Go was a problem. Said it was worth posting here to hear people's thoughts. 

Thanks!

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ed1966c2-675b-4030-911b-7fa618291985n%40googlegroups.com.

[Thomas Bushnell BSG]

This is not a problem that arises from you using Go; it's a problem arising from the fact that other people are using Go to write malware, and bad security techniques are unable to deal with it.

You could stop using Go entirely and it wouldn't change the dynamic. The better course is not to rely on scanners of the sort the article describes. Anti-virus was never a good strategy anyhow, and is in my opinion dangerous. Tavis Ormandy has enjoyed a constant stream of cases where running antivirus "protections" was actually the gateway to serious exploits.

Behavior-based detection is a good technique to use. 

--

[Gopher-Insane]

I think the concern is in using the language to wrap malware that would otherwise be detected. So not the outcome of the malware but the hiding of it.

[Gopher-Insane]

Great responses, thank you. That has helped. 

On Monday, 22 August 2022 at 14:47:55 UTC+1 Thomas Bushnell, BSG wrote:

[Axel Wagner]

On Mon, Aug 22, 2022 at 6:20 PM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

I think the concern is in using the language to wrap malware that would otherwise be detected. So not the outcome of the malware but the hiding of it.

That's a distinction without a difference. Everything we said applies the same.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7cdc8e55-b4d8-4787-8cc2-f3e15fb41718n%40googlegroups.com.

[Dan Kortschak]

On Mon, 2022-08-22 at 06:15 -0700, 'Gopher-Insane' via golang-nuts
wrote:

That's a particularly weird take that they have. Apart from the
apparent suggestion that somehow because Go is used in writing some
malware that Go should not be used, it leaves no actual action to be
taken unless your company is the origin of the malware that is
targetting it, in which case there are other issues.

The point of the article is not that novel compilation patterns are
dangerous, but rather that using compilation patterns for detection is
not a generally safe strategy for preventing malware. This is the point
that they seem to have missed.

[Jesper Louis Andersen]

How is the story in the link supporting their position? What is their position in the first place?

The story is that malware is being written in languages other than C and C++. Well, that's inevitable, because malware is an infinite arms race between avoidance and detection. The story is further that we should use behavior detection of malware, which is obviously a worthy idea. Most languages are useable as vehicles for malware, and I fail to see the reason any particular language should be singled out as being of concern.

--

J.

[Gopher-Insane]

They are suggesting that Go is being more widely used than others, making it more of a risk. 

[Ian Lance Taylor]

On Tue, Aug 23, 2022, 5:58 AM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

They are suggesting that Go is being more widely used than others,

Could be true.

making it more of a risk. 

I don't see how this follows.  What is the risk?  It's not a risk to any non-malware writer using Go.  I guess it's a risk to the malware-fighting ecosystem?  But if so, I think the answer must be to encourage more use of Go, as that will increase familiarity with the language and encourage the development of analysis tools.

(Of course this won't help in the long run, because as Go gets normalized malware authors will move on.  But there is nothing that the Go community can do about that.)

Ian

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/63527e94-331d-45bd-9d5a-019c0df4aba9n%40googlegroups.com.

[Jesper Louis Andersen]

On Tue, Aug 23, 2022 at 2:58 PM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

They are suggesting that Go is being more widely used than others, making it more of a risk. 

Is their position "we shouldn't write Go in our organization, because it's being used by malware creators elsewhere?"

I'm still confused as to what the context of this is. 

--

J.

[Gopher-Insane]

The issue is not a vulnerability in the language itself but the use of that language to embed malware so AV signatures do not detect it. The feeling is that our InfoSec will be wanting to restrict obscure languages (Go, Rust etc...).

[Brian Candler]

On Tuesday, 23 August 2022 at 15:30:49 UTC+1 Gopher-Insane wrote:

The issue is not a vulnerability in the language itself but the use of that language to embed malware so AV signatures do not detect it. The feeling is that our InfoSec will be wanting to restrict obscure languages (Go, Rust etc...).

And how exactly does choosing not to use Go/Rust in your own organization, avoid you from getting infected by malware written in Go/Rust?

[Robert Engels]

I think what is being suggested that if the sec team bans all applications that exhibit dynamic code loading behavior they’d be safer - which would catch a lot of apps in the net. 

On Aug 23, 2022, at 10:44 AM, Brian Candler <b.ca...@pobox.com> wrote:



On Tuesday, 23 August 2022 at 15:30:49 UTC+1 Gopher-Insane wrote:

The issue is not a vulnerability in the language itself but the use of that language to embed malware so AV signatures do not detect it. The feeling is that our InfoSec will be wanting to restrict obscure languages (Go, Rust etc...).

And how exactly does choosing not to use Go/Rust in your own organization, avoid you from getting infected by malware written in Go/Rust?

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a465a7ff-3e13-458d-a7f8-61c0375c38a7n%40googlegroups.com.

[Axel Wagner]

On Tue, Aug 23, 2022 at 4:31 PM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

The issue is not a vulnerability in the language itself but the use of that language to embed malware so AV signatures do not detect it. The feeling is that our InfoSec will be wanting to restrict obscure languages (Go, Rust etc...).

I think there have been ample arguments in this thread for why this is a nonsensical idea based on the concerns brought up so far. I think it would be helpful if you could try to address them.

 

On Tuesday, 23 August 2022 at 15:22:39 UTC+1 jesper.lou...@gmail.com wrote:

On Tue, Aug 23, 2022 at 2:58 PM 'Gopher-Insane' via golang-nuts <golan...@googlegroups.com> wrote:

They are suggesting that Go is being more widely used than others, making it more of a risk. 

Is their position "we shouldn't write Go in our organization, because it's being used by malware creators elsewhere?"

I'm still confused as to what the context of this is. 

--

J.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/631fa521-9209-42a5-9244-bbb1a774ef69n%40googlegroups.com.

[Brian Candler]

On Tuesday, 23 August 2022 at 16:49:57 UTC+1 ren...@ix.netcom.com wrote:

I think what is being suggested that if the sec team bans all applications that exhibit dynamic code loading behavior they’d be safer - which would catch a lot of apps in the net. 

But the article quoted makes the opposite point: "Go binaries are often statically linked—meaning that all necessary libraries are included in the compiled binary"

It also says: "Go’s large binary size causes analysis issues for some AV vendors since several security products struggle to handle larger files and have been known to just stop scanning and pass a binary if it is above a specific size."

ROFL!

[Robert Engels]

I did not read the analysis - just the thread here and earlier threads on this subject. My understanding that even though Go is statically linked the loader does relocations that confuse virus scanners. 

On Aug 23, 2022, at 11:05 AM, Brian Candler <b.ca...@pobox.com> wrote:



--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/73a6a242-ce44-4a48-8794-6f67a4b78167n%40googlegroups.com.

[Bakul Shah]

Doesn't this article in fact argue that it is the *security teams* that have to get smarter about what kind of threads they will be faced with and figure out how to deal with them?

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ed1966c2-675b-4030-911b-7fa618291985n%40googlegroups.com.

[Aaron Rubesh]

To this day the most prevalent,  evasive and destructive malware is developed in C/C++... So may as well ban those languages too!! 

Seriously, if your answer to 'stopping malware written in Go'  is to ban all applications written in Go,  your security team needs some more training budget or you need to get a new team altogether. 

Banning a language because 'the AV we pay 10mil a year for doesn't catch it'  is an insane thought process.  

Get Outlook for Android

---

From: golan...@googlegroups.com <golan...@googlegroups.com> on behalf of Robert Engels <ren...@ix.netcom.com>
Sent: Tuesday, August 23, 2022, 09:49
To: Brian Candler <b.ca...@pobox.com>
Cc: golang-nuts <golan...@googlegroups.com>
Subject: Re: [go-nuts] Is Go a security malware risk?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CD882B25-875C-48BF-9AC2-C3E003B38451%40ix.netcom.com.

[Ian Lance Taylor]

On Tue, Aug 23, 2022 at 9:29 AM Robert Engels <ren...@ix.netcom.com> wrote:
>
> I did not read the analysis - just the thread here and earlier threads on this subject. My understanding that even though Go is statically linked the loader does relocations that confuse virus scanners.

I'm not sure precisely what you mean, but I don't think that's
accurate. There is no Go loader. The statically linked binary
produced for a pure Go executable has no run-time relocations at all.

My assumption--and it is just an assumption--is roughly the reverse:
because pure Go programs are statically linked, and because the symbol
table does not use the same names as a default C symbol table, a virus
scanner has a harder time seeing which system calls are being used.
Of course the same would be true for a statically linked C program,
but perhaps malware writers tend to steer clear of those.

Obviously anything that Go is doing can also be done in C, but the
malware authors do have to work a bit harder to do that.

Ian

> On Aug 23, 2022, at 11:05 AM, Brian Candler <b.ca...@pobox.com> wrote:
>
> 
> On Tuesday, 23 August 2022 at 16:49:57 UTC+1 ren...@ix.netcom.com wrote:
>>
>> I think what is being suggested that if the sec team bans all applications that exhibit dynamic code loading behavior they’d be safer - which would catch a lot of apps in the net.
>
>
> But the article quoted makes the opposite point: "Go binaries are often statically linked—meaning that all necessary libraries are included in the compiled binary"
>
> It also says: "Go’s large binary size causes analysis issues for some AV vendors since several security products struggle to handle larger files and have been known to just stop scanning and pass a binary if it is above a specific size."
>
> ROFL!
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/73a6a242-ce44-4a48-8794-6f67a4b78167n%40googlegroups.com.
>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/DD066646-3624-4DF3-8634-44229425CF87%40ix.netcom.com.

[TheDiveO]

On Tuesday, August 23, 2022 at 8:47:11 PM UTC+2 Ian Lance Taylor wrote:

On Tue, Aug 23, 2022 at 9:29 AM Robert Engels <ren...@ix.netcom.com> wrote:
>
> I did not read the analysis - just the thread here and earlier threads on this subject. My understanding that even though Go is statically linked the loader does relocations that confuse virus scanners.

I'm not sure precisely what you mean, but I don't think that's
accurate. There is no Go loader. The statically linked binary
produced for a pure Go executable has no run-time relocations at all.

My assumption--and it is just an assumption--is roughly the reverse:
because pure Go programs are statically linked, and because the symbol
table does not use the same names as a default C symbol table, a virus
scanner has a harder time seeing which system calls are being used.
Of course the same would be true for a statically linked C program,
but perhaps malware writers tend to steer clear of those.

Obviously anything that Go is doing can also be done in C, but the
malware authors do have to work a bit harder to do that.

Ian

That's why you need to follow the defense in depth strategy. That's the reason for having things like seccomp (for syscall filtering), LSMs like AppArmor and SELinux (MACs), ... however, these are no silver bullets and actually either cause a false sense of security (especially AppArmor when it comes to not only Linux container technology using mount namespaces) or can easily grind your system to a total halt, like messing up your SELinux labels, preferably by your favorite long-term (in)stable Linux distribution not understanding the importance of certain file system tools in correctly handling extended file attributes containing SELinux labels. You need a great deal of deep understanding to operate them correctly and to achieve more than just to superfluous token security that your vendor delivers.

When an InfoSec starts to argue about Go (C, C++, JavaScript, ...) being unsafe, that enterprise has the worst enemy it can get: its own InfoSec. They have drunken deep from the well of Security Vendor cool aid.

[Robert Engels]

Doesn’t a different structure as per the Go FAQ imply a specialized loader /runtime linker? I just assumed it did.

> On Aug 23, 2022, at 1:47 PM, Ian Lance Taylor <ia...@golang.org> wrote:

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW4kJbMswGH18fRrX66-Ty3nGrYRDpnWQcf9H56Wrnsew%40mail.gmail.com.

[TheDiveO]

UPX, the Ultimate Packer for eXecutables https://github.com/upx/upx is also a specialized loader. Does not only shrink Go binaries, but https://words.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/ made me aware of it when I had fun with a discussion about container image sizes. UPX looks like a nice horror story to feed to your InfoSec, driving them step by step over the edge if they're so inclined.

[Henry]

Should a knife maker be held liable and required to 'fix' their knives when their knives are used in criminal acts? If the knives are made specifically with the sole purpose of breaking the laws, then yes, the knife maker should be held liable. If the knives are general purpose tools, then no, the knife maker has nothing to do with it. You can even kill someone with something as innocent as pillows. There is no end to human ingenuity, including their ability to commit crimes.  

This is the case of security vendors trying to shift responsibility and blame to the language makers. Technology keeps changing and those AV folks need to keep up.

[Ian Lance Taylor]

On Tue, Aug 23, 2022 at 2:23 PM Robert Engels <ren...@ix.netcom.com> wrote:
>
> Doesn’t a different structure as per the Go FAQ imply a specialized loader /runtime linker? I just assumed it did.

Go has a different program linker that generates the statically linked
executable, but a statically linked executable does not require a
loader or runtime linker.

[Gopher-Insane]

Thanks, everyone for your replies. This will really help. 

[Amnon]

I learned a few things from the article.
Apparently Go is an "unconventional language".  So Languages are divided into "conventional" and "unconventional"
languages.
I know a few languages. Some are statically typed, some have dynamic typing. Some are interpreted and some are compiled.
But I don't really know how one defines a conventional vs an unconventional language, and how we distinguish between them,
and what its properties are.

The other thing I learned was that Go is a relatively new language. 
I was under the mistaken impression that Go has existed for quite a while - for over a decade.
I thought that Go was first publicly launched in 2009 - an eternity ago in the fast paced world 
of software engineering. But perhaps the world of corporate security software moves at a more 
glacial pace, building systems and scanners which deal with languages threats from decades ago. Perhaps their 
definition of "new" is different from that of people in the rest of the tech world. This may explain the ineffectiveness
of corporate security systems in preventing a whole series of devastating ransomware attacks on high profile organisations.

More seriously, I do agree with the conclusion of the article, that security tools need to focus on the behaviour of software
rather than looking for signatures in a list of known pre-existing malware. 

[Holloway Kean Ho]

Hi,

I be very blunt here:

1. What exactly you're trying to achieve by taking a very elaborated, crystal-clear, good-willed security-related article way out of its context with your thread title here and agitate some of the Go maintainers here?
   

Why I'm asking:

• AFAIK, behavior scanning technique was long implemented in their AV runtime detection (some time ago, comsumer product AV was requested to tone down such method because it took so much resources to the point where the CPU is too busy to the point of unsable) alongside the common signature pattern matching technique.
• I still hear Go developers on Windows complaining about their AV blindly deleting their compiled Go binaries during their development.
• The article specifically mention Go because Go had long achieved one of its 'ease of use' strength so it's not surprising that it will become a staple language for both good and maliciously motivated software in near future.
• Security is about constant learning, exploring, testing (including outside the box thinking), and sharing. It's a habit and an attitude; not a job. Go, Rust, C, C++, POSIX Shell, etc are merely tools. In fact, if you comprehend the article correctly (2nd last paragraph), it implies that you should and shall acquire these new tools and then upgrade your arsenals ASAP collaobratively.
• Security is a constant "cat chasing mouse" aspect. Sometimes the sword is better than shield; sometimes the other way round; sometimes some people misconfigured a pizza as a shield; sometimes you encounter manager brought a properly configured shield offline for the sake of "convinence" and "too much to learn". Given so many probability of disaster, the last thing is to actively denying innovation (as in birth of new tools like Go, Rust, etc) that builds better sword and shield.

I believe you already have you answer from the get-go.  Peace.

Regards,

Holloway

[Dan Kortschak]

On Thu, 2022-08-25 at 01:47 -0700, Holloway Kean Ho wrote:
> What exactly you're trying to achieve by taking a very elaborated,
> crystal-clear, good-willed security-related article way out of its
> context with your thread title here and agitate some of the Go
> maintainers here?

I don't think that's what the OP was doing. Bill Kennedy suggested they
ask here, and I think that they have enough information/ideas to take
back to their security team to address the misconceptions that they
have.

[Gopher-Insane]

Apologies if this caused offense. That was never the intention. I am a big fan of Go myself, and this was raised to me by our Security team. I was seeking the advice of experts in the field to help me build an argument. I do fully appreciate everyone's help. 

[Gopher-Insane]

Thank you kortschak, yes that was all I was doing. Seeking advice from people who have better knowledge than me in this area. Again, very grateful for everyone's help. 

[Holloway Kean Ho]

All right. In that case, you can point the same article's 2nd last paragraph which is very self-explainatory.

This book (§1, §2, and §7.5) should give you a quick basic: https://www.cs.ox.ac.uk/andrew.ker/docs/computersecurity-lecture-notes-mt2014.pdf

This book should you give you a rough idea about introduction to specifically computing security technical aspect. Security itself has a lot of aspects.: http://www.uoitc.edu.iq/images/documents/informatics-institute/exam_materials/Introduction%20to%20Computer%20Security%20pdf%20DONE.pdf

This manual alone (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html) can give you an idea that a system security (hardware+software) is about controlling quite a large number of aspects and considerations than being picky with a programming language is the very last thing to consider.

1 additional point to counter to the counter-argument is: neither one (within computing security scope alone) mention specifically of a programming language being a threat since most of contents are theorems, threat model + countermeasures, practices, etc etc.

The argument about behavorial detection in consumer-product AV: https://usa.kaspersky.com/resource-center/definitions/heuristic-analysis

And difference between behavorial detection vs heuristic analyis: https://security.stackexchange.com/questions/157797/what-is-the-difference-between-heuristic-based-and-behaviour-based-virus-scannin

Of course, given the current geo-political situation, you can search "heuristic analysis" of the AV of your choice and find out when they started the implementation. For Kas (I used to use it when I was on Windows OS long time ago), if I'm not mistaken, it was implemented all the way back since the transition from Windows XP to Windows 7 era. The rest of the competitors: I'm not aware of it.

> Apologies if this caused offense. That was never the intention. I am a big fan of Go myself, and this was raised to me by our Security team. I was seeking the advice of experts in the field to help me build an argument. I do fully appreciate everyone's help. 

Nahh, no worries. Be careful with framing the title next time. Some forums' zealots will skin you alive with that kind of touch.

 

Regards,

Holloway

[Jesper Louis Andersen]

On Thu, Aug 25, 2022 at 7:54 AM Amnon <amn...@gmail.com> wrote:

Apparently Go is an "unconventional language".  So Languages are divided into "conventional" and "unconventional"
languages.

Any language split like this often fails to capture the essence of different language designs. We should use precision in our categorization of programming languages, and we are often failing.

--

J.

[Jonathan Reiter]

Hi there,

I agree with Holloway here, and raise a very specific point. If the poster's fear is with a new language bringing additional polymorphism to malware, I would say there are *far* easier ways to permute a binary and thus make it resistant to either reversing or signature based detection. Packing, fileless mechanisms, and cryptographic seeds all come to mind, and none of them imply using Go. In fact, adding another language to the mix only serves to complicate matters.

IMHO the trend in the field is less of Go being part of the malware supply chain because of polymorphism, and more of its use because it is simpler to write system (and server, in the case of C2) code. Happy to share some sources on this topic if folks are interested in a deeper dive.

Best,

Jonathan

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/682d8bda-825e-4e97-9b4c-c4d24fdd5326n%40googlegroups.com.