Conduct an Audit

[Dadadah]

I assume you have regained control of your security keys.

I think this project is large enough to fund an open source audit to alleviate any concerns about security compromises.

These things can happen and there are things the repository owners can do to address it.

Initial research shows an audit taking about US$100/1000 lines of code.

Perhaps consider starting a fundraiser for it @lawl ?

[lawl]

No i havent. I believe its unrelated to noisetorch, but better safe than sorry. I am dead right now and dont have the energy to rebuild my computing devices from scratch.

Everythings still compromised, but hopefully enouch people know now.

[OldiLo]

Should I remove NoiseTorch and ayy project?

[CheaterTim]

@OldiLo

Should I remove NoiseTorch and ayy project?

I would remove both for now and watch out for any updates regarding the situation

[OldiLo]

I assume you have regained control of your security keys.

I think this project is large enough to fund an open source audit to alleviate any concerns about security compromises.

These things can happen and there are things the repository owners can do to address it.

Initial research shows an audit taking about US$100/1000 lines of code.

Perhaps consider starting a fundraiser for it @lawl ?

Maybe the community should do it

[lawl]

No, dont give money. Patreon is scheduled for deletion cant do it instantly.

[OldiLo]

No, dont give money. Patreon is scheduled for deletion cant do it instantly.

No, the community can do an audit

[YannikSc]

Can't you just revert from a fork? How long ago was the breach?

EDIT

With that I don't want to say, that you should fix it, its more like a thought, if someone wants to revive the project, and I'm rather asks for an estimation if this could be plausible way to get some sort of fix together.

Would be hard though if it was a couple months or even years ago.

[comfmai]

So I did a little digging:
This is the original binary version, for some reason it was compressed with UPX, which should have raised my suspicion (but I can see the previous versions are also UPXed, @lawl is this on purpose?)

I put it through VirusTotal, it came out clean
https://www.virustotal.com/gui/file/726a3dd0b72d2de56b55d2920fd1ea64c5017983eb308f3e3bfba2dbe867ea94/detection

I also the unpacked version through VirusTotal, it came out clean as well
https://www.virustotal.com/gui/file/23d531efde629161f64294a6f13a7c9ad7a6df06435d2fcc9f6604848959a2ac/detection

But, when firing WireShark I can see this:
TLS connection being made to 82.118.227.155 , which seems to be already reported: https://www.abuseipdb.com/check/82.118.227.155

This looks like a command & control server...

[lawl]

Yes upx was on purpose, but ypu shouldnt trust me when i say that because i already said my sytem(s?) were compromised.

[lawl]

82.118.227.155 have you checked this isnt the update server? Does noisetorch.epicgamer.org resolve there?

[Xunjin]

Yes upx was on purpose, but ypu shouldnt trust me when i say that because i already said my sytem(s?) were compromised.

I see well I've looked for this IP and I found not a single reference using wireshark as @comfmai found out. However, I'm not an expert on this.

@lawl I know you are tired and feeling really depressed about it, however if there is a way for us to help you, maybe conduct some kind of audit. This project is way too good to die 😢

Edit: tho I'm using the arch repo https://aur.archlinux.org/packages/noisetorch, and it's indeed old.

[lawl]

Ok ive pointed the readme to this thread. If we can get enough people to check the code, maybe we can work from there.

[papaya2k]

Name: noisetorch.epicgamer.org
Address: 82.118.227.155
Name: noisetorch.epicgamer.org
Address: 2a01:8740:1:fe3f:dc78:593f:d16c:1

[Widward1]

That is the hostname of my install, I have already uninstalled it, but is there anything else that I should do?

[reynoldsme]

So, noisetorch.epicgamer.org does resolve to 82.118.227.155 but it also resolves to the ipv6 address 2a01:8740:1:fe3f:dc78:593f:d16c:1 so @Xunjin you wouldn't necessarily see any references in wireshark to the 82.* address if testing from an ipv6 enabled network and machine.

[papaya2k]

So, noisetorch.epicgamer.org does resolve to 82.118.227.155 but it also resolves to the ipv6 address 2a01:8740:1:fe3f:dc78:593f:d16c:1 so @Xunjin you wouldn't necessarily see any references in wireshark to the 82.* address if testing from an ipv6 enabled network and machine.

Don't know where others are from, but a lot of American ISPs including my own don't provide IPv6 access to the Internet.

[protectroot-com]

I was only sharing a good resource. I follow the owner of sandfly security on twitter. He is the best security expert on Linux IMHO. https://twitter.com/CraigHRowland

[TheDukeofErl]

2- For every dependency in the vendor folder, check if the code matches with the same version of the dependency in its original repo. The git repo of every dependency found in vendor/ can be found in go.mod.

Went and did a somewhat lazy way of doing this just by deleting the vendors folder and doing a go mod vendor, git diff returned that there were no differences by doing this so it's likely the vendor folder is fine. I didn't check the c/ folder though. It looks like that's more or less just vendor code (rnnoise and ladspa) so the same thing should be doable there.

One thing that's worth noting here is that the https://github.com/lawl/pulseaudio dependency may need some additional inspection, as that repo is also owned by lawl. It doesn't look like there's too much code there though, thankfully.

[ZyanKLee]

I verified the vendor folder with the same approach. ✔️

[Namenot]

Regarding the https://github.com/lawl/pulseaudio dependency, I doubt that it contains anything malicious (at least not from the current compromise) as there are only 2 commits in it from around q3, one was commited in June and the other in September. Both hardly change anything (less than a line of code each). Neither looking sus to me tbh. But I'm not a go dev so maybe I'm mistaken.

[AXDOOMER]

I went through https://github.com/lawl/pulseaudio twice and didn't see anything suspicious. I haven't yet finished going through NoiseTorch's source code.

@lawl Are there reasons to think your Github was compromised? (password reuse between the server and Github, RSA private keys or SSH private keys on the server?) Did you use password authentification on the server?

IMO NoiseTorch's update process should be changed so updates are pulled directly from Github releases rather than a server on the Internet.

[ZyanKLee]

Thanks @AXDOOMER for taking the time of looking through the code of the pulseaudio library.

I agree that the releases should be discovered and pulled from github releases. Let's put it on the list of things to be done in the next days/weeks.

[TheDukeofErl]

I've checked c/rnnoise against https://github.com/xiph/rnnoise, this dependency looks fine as well.

I know #257 was closed but I think it's worth revisiting. It would probably be good to investigate moving other dependencies, like rnnoise, out of the repo in a similar manner.

[TheDukeofErl]

Verified c/ringbuf.* against https://github.com/dhess/c-ringbuf.

[TheDukeofErl]

I've made a PR that removes both rnnoise and c-ringbuf as code and instead uses submodules: #268. Once the audit is done it can be tested then merged.

[OldiLo]

I made pr #269 for small fix and update dependencies

[TheDukeofErl]

I've finished verifying c/ladspa, it looks good to me.

.gitignore:	fine, verified manually
export.txt:	fine, verified manually
ladspa.h:	fine, verified against upstream (https://www.ladspa.org/ladspa_sdk/ladspa.h.txt)
Makefile:	fine, verified manually
module.c:   	fine, verified manually, based on ladspa_sdk/src/plugins/filter.c
utils.h:	fine, verified against upstream (https://www.ladspa.org/ladspa_sdk/overview.html)

This concludes my review of the c/ folder.

[ZyanKLee]

I will move this ticket to discussions for now. We are actually touching too many topics here for it to be an actual issue ticket.

[MoJo1760]

@lawl I'm not the best at code review, but I do things on the offensive side of security including chasing bad actors - can I help in any way?

[viniciusnevescosta]

Hello everyone, well, I'm a little lost about what happened, but my microphone started getting buggy (understand buggy as, popped and inaudible).

I was using noise torch normally but I decided to enter its repository, which contained some instructions to uninstall it, so I did.

I don't know if these 2 facts correlate, but I would like to know why uninstall this program that until recently was normal. If you can explain to me what really happened, thank you!

[viniciusnevescosta]

My mic is still buggy even though I uninstalled the program

[Dany-Wilde]

debian sid unstable . for me, everything works fine .
where should I investigate ? what should I look at ? what tests should I do ? in what way ? with what command(s) ? if I can help ...
I'm a beginner in development. I don't know anything about it and, at my age, I don't understand a lot of things.

[viniciusnevescosta]

debian sid unstable . for me, everything works fine . where should I investigate ? what should I look at ? what tests should I do ? in what way ? with what command(s) ? if I can help ... I'm a beginner in development. I don't know anything about it and, at my age, I don't understand a lot of things.

Hi, did you have any problems with respect to microphone or even privacy/security?

[ZyanKLee]

@Jolonte your microphone issues are not the result of the original author's PC having been hacked. If something broke and is still broken after you uninstalled NoiseTorch, you should search the issue elsewhere. For example with the drivers, pulseaudio/pipewire or your kernel.

[viniciusnevescosta]

Yes, actually it has already been corrected. Via this issue: #273

[Rififia]

Do we have infos about the update server? Was it compromised too? We might have to check it too (but no idea how) to be sure it didn't trigger fake updates.

[ZyanKLee]

Probably not, but we can't rule it out at this point. We are thinking about replacing it with GitHub releases. See #272 and #271

[Rififia]

Yes, this is a good idea for the future. My question was more directed towards whether the server has been an attack vector, but as you say, we can't infallibly know for the moment.

[ZyanKLee]

I checked the Makefile and am pretty sure that in it itself there is no malicious code. Though I got two work packages out of the review: rework the update process with GH releases in #272 and #271

[Namenot]

I'm fairly inexperienced when it comes to github and code review, so excuse my naivety, but wouldn't it suffice to 'just' got through all commits done since the compromise instead of going through the whole code? Anyhow I still wanna help so if someone can point me in the right directions that would be nice as i have never done an audit myself and don't really know how to approach one.

[ZyanKLee]

given the right permissions, one could easily rewrite the whole git-history. Therefore I would deem it easier to review the current state and when that is in an apparent clean state, we can continue from there.
I'm not a security engineer myself, though, and one with that background could have another opinion on that matter.

As for how to help:
We got an overview of elements we need to check and read through at #275. If you feel you are somewhat experienced in any of these technologies, please feel free to do what you think is needed to verify its integrity.
After that leave a comment in #275, explaining what you did (so others can verify) and if you found anything suspicious.

[maggick]

I check the short Makefile. Nothing malicious there.
It just call go run scripts/signer.go.

Nonetheless it calls system binary (as go, tar or upx) if @lawl computer was fully compromised this system commands should not be trusted and so the binary should not be trusted. A new build should be fine once we reviewed the whole code.

[ZyanKLee]

Thank you for giving it a quick glance. I came to the same conclusion: it's too short and tidy to really hide something in there.

[ZyanKLee]

Folks: YOU ARE AWESOME!
Thanks a lot for all the help with this code review. I'm glad you are here and helped out; I could not have done that without you (quite literally).

Next goal is to create a new stable release with a working update mechanism #271 - perhaps someone wants to pick up that ticket and train those coding muscles a bit?

[ZyanKLee]

PS: I'll lock this topic soon, as we are done with the audit. If you wanted to add something to it afterwards, just open another discussion.

[ZyanKLee]

Due to a suspected security breach of the update server and code repository, there's
been a concerted effort by the NoiseTorch community to ensure the source code and
binaries are free from malicious code.

No malicious code has been found.

You can read more about the audit that was done here
and here.
Updates will now be retrieved from the project's releases page to avoid any risk
of this reoccurring. We thank everyone for their trust and the love that they've
shown towards the project in this unpleasant time.