Trojan:Win32/Sabsik.TE.A!ml in target x86_64-pc-windows-msvc

[jophj]

I'm getting a compromised exe from this action. Microsoft Defender recognizes it as Trojan:Win32/Sabsik.TE.A!ml. The exe built by this action differs from the one I built locally. I only tested Windows.

❯ diff sabikonbata.exe sabikonbata-compromised.exe
Binary files sabikonbata.exe and sabikonbata-compromised.exe differ

You should be able to reproduce this issue with the following config easily:

name: Release

permissions:
  contents: write

on:
  release:
    types: [created]

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/create-gh-release-action@v1
        with:
            # (required) GitHub token for creating GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

  upload-assets:
    needs: create-release
    strategy:
      matrix:
        include:
          - target: aarch64-unknown-linux-gnu
            os: ubuntu-latest
          - target: aarch64-apple-darwin
            os: macos-latest
          - target: x86_64-unknown-linux-gnu
            os: ubuntu-latest
          - target: x86_64-apple-darwin
            os: macos-latest
          # Universal macOS binary is supported as universal-apple-darwin.
          - target: universal-apple-darwin
            os: macos-latest
          - target: x86_64-pc-windows-msvc
            os: windows-latest
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/upload-rust-binary-action@v1
        with:
          # (required) Comma-separated list of binary names (non-extension portion of filename) to build and upload.
          # Note that glob pattern is not supported yet.
          bin: sabikonbata
          target: ${{ matrix.target }}

          # (optional) On which platform to distribute the `.tar.gz` file.
          # [default value: unix]
          # [possible values: all, unix, windows, none]
          tar: unix
          # (optional) On which platform to distribute the `.zip` file.
          # [default value: windows]
          # [possible values: all, unix, windows, none]
          zip: windows
          # (required) GitHub token for uploading assets to GitHub Releases.
          token: ${{ secrets.GITHUB_TOKEN }}

FYI this is my affected repo: https://github.com/jophj/sabikonbata. I'm removing the compromised artifacts and the GitHub Actions configuration but you should be able to fork it and reproduce the issue

[taiki-e]

I have looked at your workflow logs, and this action appears to be running fine, assuming there are no problems with action runners, installed programs, and your crate's dependencies. (In other words, this action does not appear to be causing any problems, and either it is a false positive or there are problems elsewhere.)

FYI, here is the code that your workflow actually used (action.yml and main.sh have the actual code for the action):
https://github.com/taiki-e/upload-rust-binary-action/tree/aefa20ac5893ee9a660dd3e995c9dc9a715e93f0

Windows recognize

Do you mean "windows defender"? Or is it other anti-virus software?
Is it possible to use virustotal.com to have a bunch of different anti-virus software scan the binary? (Like rust-lang/rust#93187 did)

The exe built by this action differs from the one I built locally.

Depending on how you built the binaries locally, this is usually normal. The compiler will embed information into the binary, such as the path where the build was performed, and this action will perform a strip on the resulting binary.
(FYI rust-lang/rust#34902 has more information about reproducible builds)

[jophj]

Do you mean "windows defender"?

Yep, I fixed the description.

This is the virustotal.com scan result:
https://www.virustotal.com/gui/file/e7ae393b561c1d502aa606b1f4dbfd5e930cbbc5d9b9773fdf3df15a49367b45/detection

It may be a false positive, but it looked strange to me that Windows Defender it's only triggered by the GitHub build, and not by my local build

[taiki-e]

Updates in the last few days or weeks in virustotal seem to indicate that it is no longer detected.

---

It may be a false positive, but it looked strange to me that Windows Defender it's only triggered by the GitHub build, and not by my local build

One possibility is that the version of the database used inside Windows Defender is different (between local and virustotal). And that, combined with the fact that this action stripped the debug info, may have accidentally caused the problem of matching (or no longer matching) a particular signature.
strip will be the default in the next stable (1.77, rust-lang/cargo#13257), you may no longer encounter this type of problem.