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 On Thu, Aug 25, 2022 at 1:47 AM Holloway Kean Ho <hollowaykea...@gmail.com> wrote: > 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 > > On Thursday, August 25, 2022 at 1:54:47 PM UTC+8 Amnon wrote: > >> 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. >> >> On Wednesday, 24 August 2022 at 10:15:43 UTC+1 Gopher-Insane wrote: >> >>> Thanks, everyone for your replies. This will really help. >>> >>> On Wednesday, 24 August 2022 at 06:28:04 UTC+1 Ian Lance Taylor wrote: >>> >>>> 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. >>>> >>>> Ian >>>> >>>> > > On Aug 23, 2022, at 1:47 PM, Ian Lance Taylor <ia...@golang.org> >>>> 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 >>>> > > >>>> > > >>>> > >> 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. >>>> >>>> > > >>>> > > -- >>>> > > 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/CAOyqgcW4kJbMswGH18fRrX66-Ty3nGrYRDpnWQcf9H56Wrnsew%40mail.gmail.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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/682d8bda-825e-4e97-9b4c-c4d24fdd5326n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/682d8bda-825e-4e97-9b4c-c4d24fdd5326n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAC41hdMBXQ0HoRC3NNQmj%3DviZVdQ5R9iJFVqOBH1gZY3%2BkX%2Bgg%40mail.gmail.com.
