Jump to content

YvetteS

Members
  • Posts

    14
  • Joined

  • Last visited

Posts posted by YvetteS

  1. Mieke,

     

    Thanks for your PM,  as well as the link to the discussion on False Positives.

    Upon reading that section,  I see my local,  non-published code doesn't have some of the recommendations given in your False Positive section (which is why your false Positive section recommends that we exclude our projects in development).  

    So it looks the workaround mentioned above ("go build" rather than "go run"  while building in an excluded directory) is a good way to deal with this issue while code is still in development.

    @Golang developers of the world

    (Unless there's some setting in Golang that will make the go run... command put the temp exe in a more "excludable" directory that the local temp directory)

    Thanks for your patience and the explanation

     

    - Michele

     

     

  2. Mieke,

    Thanks for your response!  For my future benefit,  can you let me know if there is a specific format/specific information you'd like to see when I am putting in version information?

    However,   I also want to make sure we aren't missing something in communication. 

     

    ********TL;DR  I am not sure versioning will help in this particular case,  Machine Learning may not work on this type of problem.  My workaround still works for my needs.  If the problem cannot/should not be resolved by an Engineer,  it might be good to publish the workaround for Golang programmers.*******

     

    I am not trying to get MalwareBytes to ignore specific files or even to ignore new versions of the same software.  I am trying to get MalwareBytes to ignore a specific type of command .  

    Since the files are so small,  I can tell that MalwareBytes is choking because of a specific type of command in the file.  This leads me to believe that it has been specifically "taught"  to look for that particular type of command and not allow it to run.  And this particular command is going to show up all over the place in all kinds of people's files.

    IF that is correct, then whitelisting a few files that have that specific line of code likely won't fix the problem - even if the files have versioning.    Machine learning probably cannot actually learn to disregard a particular command it has been specifically taught to flag,  simply because it has been taught to ignore some specific  files with that command.    That might take an engineer stepping in.  

    As I mentioned,  I have a workaround now,  so this is not an emergency for me simply learning tutorials.  However, for current and future Golang programmers,  it might be worth it to have someone take a look at the particular flag that is being tripped by these very short files. 

    Not necessarily to change the flag,  but to understand how the flag will affect some Golang programmers.  If it is not possible to change the flag,  it might be good to put out a notice to Golang programmers on how to work around it when they have MalwareBytes installed.

    But in any case, thank you again for your help!

    - Michele

     

     

     

     

     

     

     

  3. Plain Get.zip has a couple of very simple go programs with their .go source and exe files,  which use http.Get in Go

     

    Now due to the fact that,  in the link I included in the OP,  Nathan Smith writes:

    Quote

    Go’s http package doesn’t specify request timeouts by default, allowing services to hijack your goroutines. Always specify a custom http.Client when connecting to outside services.

     

    I'm wondering if it is possible that MalwareBytes might eventually decide they don't like simple http.* calls.

    So, just in case you'd rather just Whitelist the safer version of these http.Get calls,  I have also included two slight alterations of Nathan Smith's example workaround in the article I linked to in the OP.  (These files also have very small amounts of code, and they trigger the same problem in my machine)

    See NathansGet.zip
     

    Plain Get.zip NathansGet.zip

  4. Mieke,

     

    **************************
    ETA:  The workaround turns about to be to use go build main.go rather than go run main.go.  This makes the file compile an exe in my project folder (which did exclude) instead of the temp folder,  and I can run that successfully.  I'm leaving the earlier version of this post up,  since it may be useful to find a solution to the problem that occurs when you use go run rather than go build, but at least I know of one workaround.  Thanks again for all your help!!

    ****************************************

    I had put an exclusion on the Golang folder in Program Files (where the Go software is located) and an exclusion on the folder for my Golang project where I compile and run all my source code.  But  I was still having the problem until after you told me you had whitelisted the specific file.  

    But then I still had problems when I compiled a similar file.

    It looks running my go file creates new main.exe's in Temp folder each time I run - even for the SAME Golang file run multiple times.  I don't think I can solve the problem by white listing a folder:

    You see that in this path...

    C:\Users\Developer\AppData\Local\Temp\go-build310021942\b001\exe\main.exe

    That the first "Go specific" folder is go-build310021942. Those numbers won't be the same for every build of every go file. 

    (And obviously you wouldn't want me to  blanket whitelist my Temp, Local, or AppData folder!)

    Further I find that the folders are created and deleted very quickly during program execution,  so it would be hard for me to grab the main.exe for you.

    Sadly,  I'm going to have to take back what I said about whitelisting each of these temp files as a workable solution!

    Now I HAVE noticed that when I rebuild the file that you said you whitelisted, it has a different number in its Temp\go_build####.. folder,  according to your LOG file,  but Malwarebytes still manages to whitelist it just fine.

    So I'm guessing you've done something on your end that can recognize - and whitelist-  new builds of the same file.  

    In any case, here is the code from the new file that DOES NOT work.   You can see how close it is to the whitelisted file's code (I changed World to Haha)

    package main
     
    import (
        "fmt"
        _ "net"
        "net/http"
    )
     
    func main() {
        fmt.Println("Hello Haha")
        //var _ = http.CanonicalHeaderKey("bob")
        _, _ = http.Get("https://www.google.com/robots.txt")
        fmt.Println("Goodbye World")
     
    }

    Here is a new Log snippet also attached for the minute that the not-working go file was running.  You can see again the detection:

    "DDS-IG Detection on file C:\Users\Developer\AppData\Local\Temp\go-build290878521\b001\exe\main.exe"

     

     

     

     

     

     

  5. Mieke,

    I had put an exclusion on the Golang folder in Program Files (where the Go software is located) and an exclusion on the folder for my Golang project where I compile and run all my source code.  But  I was still having the problem until after you told me you had whitelisted the specific file.  

    But then I still had problems when I compiled a similar file.

    It looks running my go file creates new main.exe's in Temp folder each time I run - even for the SAME Golang file run multiple times.  I don't think I can solve the problem by white listing a folder:

    You see that in this path...

    C:\Users\Developer\AppData\Local\Temp\go-build310021942\b001\exe\main.exe

    That the first "Go specific" folder is go-build310021942. Those numbers won't be the same for every build of every go file. 

    (And obviously you wouldn't want me to  blanket whitelist my Temp, Local, or AppData folder!)

    Further I find that the folders are created and deleted very quickly during program execution,  so it would be hard for me to grab the main.exe for you.

    Sadly,  I'm going to have to take back what I said about whitelisting each of these temp files as a workable solution!

    Now I HAVE noticed that when I rebuild the file that you said you whitelisted, it has a different number in its Temp\go_build####.. folder,  according to your LOG file,  but Malwarebytes still manages to whitelist it just fine.

    So I'm guessing you've done something on your end that can recognize - and whitelist-  new builds of the same file.  

    In any case, here is the code from the new file that DOES NOT work.   You can see how close it is to the whitelisted file's code (I changed World to Haha)

    package main
     
    import (
        "fmt"
        _ "net"
        "net/http"
    )
     
    func main() {
        fmt.Println("Hello Haha")
        //var _ = http.CanonicalHeaderKey("bob")
        _, _ = http.Get("https://www.google.com/robots.txt")
        fmt.Println("Goodbye World")
     
    }

    Here is a new Log snippet also attached for the minute that the not-working go file was running.  You can see again the detection:

    "DDS-IG Detection on file C:\Users\Developer\AppData\Local\Temp\go-build290878521\b001\exe\main.exe"

     

     

     

     

     

     

    MalwareCliffNotesLog2.txt

  6. Thank you Mieke,

    I checked this morning and was able to run my program.  Thank you.  However, as soon as I wrote a new simple main.go file in new subdirectory,  with virtually identical code,  I ran into the error again.

    I think this means will have to white list file in my temp folder every time I build a new main.go file which has http.Get or similar calls.  This is a workable solution for me right now,  since I'm only doing basic tutorials.

    However,  Malwarebytes may want to look into this further,  in case some real Go developers run into this  now or in the future.

    Again, I appreciate your help!

  7. Hello Mieke,

     

    Thanks for reaching out.

    The main.go Golang file will use go.exe, and I notice from the log that other Go related exe's are being called.

    I've attached a shortened snippet from the log.   In order to capture the snippet,   executed go run main.exe in Windows command prompt.  I waited until 15:44 to enter the command,  and noticed that my go file stopped running and returned the prompt to me before 15:46.  So I copied out some data from the log file from 15:44 to 15:46  (I did notice some of the logs time stamps are out of sequence,  but I think it's generally following the order of minutes)

    As you can see, there is a problem detected:

    "DDS-IG Detection on file C:\Users\Developer\AppData\Local\Temp\go-build310021942\b001\exe\main.exe, ThreatName=Malware.AI.3977460092, RuleString=F592C1B24271AC3BED13397C."

    Again, please note that I've run several Golang programs in the same directory without being stopped, and I'd be able to run this very file if I just removed the Get call.

    Let me know if this is enough or if you need more information.

     

    Thanks!

     

     

     

     

     

     

    MalwareCliffNotesLog.txt

  8. This very simple code in a main.go file...

     

    package main
    
    import (
        "fmt"
        _ "net"
        "net/http"
    )
     
    func main() {
        fmt.Println("Hello World")
        //var _ = http.CanonicalHeaderKey("bob")
        _, _ = http.Get("https://www.google.com/robots.txt")
        fmt.Println("Goodbye World")
     
    }

    ... does not work if my MalwareBytes (Premium, in my case) is on.  I run it with a simple go run main.go command.

    It will run for a few seconds,  and then returns me to the prompt with no errors and no output.  (Not even the Hello World, which comes before,  and has nothing to do with,  the http.Get)

    Turning off Malwarebytes allows the Hello and Goodbye World to show up.

    (I should probably mention ... Now,  I HAVE heard elsewhere that Go's http.Get is bad practice in production,  (see here if curious

     https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779)

    .  I don't know if Malwarebytes decided to specifically block calls for anything related to the article.  But even the recommended workaround in that article  .. (defining an http.Client)  didn't seem to work for me.

     

     

     

     

  9. CatByte,

    Just wanted to follow up on something you said:  You quoted the EULA as follows: 

    "provided that your usage shall be governed by the terms and conditions of this Agreement applicable to Malwarebytes for Business users and not the terms and conditions applicable to Home users. (“Small Business Exception”). "

    So I took a look at the Business section and I noticed that it said the license was for " you to use the Software solely for your internal business purposes. "

    So then would it be a problem if my home devices are for both business and personal use?  Or is this more of a reference to, for example,  hosting a client website on your machine?

    - Michele

     

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.