Audacity version 0.10.1 is vulnerable to DLL Hijack, it tries to load “avformat-55.dll” without supplying the absolute path, thus relying upon the presence of such DLL on the system directory.
Resulting in an exploitable DLL Hijack vulnerability, even the the SafeDllSerchMode flag is enabled.
Usually dll hijacking attacks require (low) access to the machine.
If a low privileged user is infected, a malware is capable of injecting code into Audacity process (and steal audacity data or user data) without the need of privilege escalation (i.e. ability to write to Program Files and/or system32).
We receive occasional reports about this but we deem this to be a negligible risk which you will encounter with most other software too.
By the way, we don’t make Audacity “0.10.1” so that is nothing to do with us.
Gale
Sorry for my mistake, the vulnerable version is 2.1.2 and not 0.10.1.
Hello there.
Is this issue fixed in 2.1.3? I don’t find anything related in the release notes.
I just came across this via Secunia, where this issue is considered “Highly Critical”. And I must agree to them, this is not an “negligible risk” to me.
I put some references in here:
Original Advisory:
http://seclists.org/fulldisclosure/2017/Jan/att-2/Advisory_-_Unsafe_DLL_in_Audacity.txt
Secunia Advisory:
https://secuniaresearch.flexerasoftware.com/advisories/74570/
I think, by reading the Advisories the impact of that issue gets much clearer…
Greets, Claus
It is “highly critical” if someone is able to put a malicious DLL onto your computer, regardless of whether you have Audacity installed or not.
This is really a matter for the Audacity developers rather than the forum, and the Audacity developers are aware of the issue.
Since you asked about it here on the forum, I can give you my personal take, which is that the report is somewhat misleading. For a DLL Hijack to occur, it is necessary that the computer is already compromised. Dynamic loading is necessary for many applications, including Audacity, and Microsoft provide mechanisms for that purpose. There are many measures that software developers can take to limit the risk of DLL hijacking, but Microsoft and all reputable security advisors recognise that it is impossible to eliminate the risk.
The text file that you link to is also misleading by suggesting that the Audacity developers “neglected the risk”, when I know for a fact that this issue has been discussed at length by the developers on more than one occasion.
Some general advice about security is provided on our website: Redirecting to: https://www.audacityteam.org/FAQ#is-audacity-safe-to-download
Hello there.
I just did some tests on my own, because steve said its only an issue when the PC has the malicious DLL on the computer already. The Security report by Felipe Xavier Oliveira and Secunia say, that this issue is exploitable from remote. So, two different opinions. I really wish Steve would have been right, but I think my tests clearly show, that its VERY EASY to make a User loading the (potentially malicious) DLL from REMOTE!
I don’t want to give all the details here, but you can make a user open a Audacity-Project on a Network Share with 3 simple clicks! And YES, Audacity is executing the DLLs next to the Projectfile. Not only avformat-55.dll but also avcodec-55.dll and avutil-55.dll! So, someone who’s able to manipulate those DLLs to run his own code is able to infect systems from remote in 3 clicks and having that code running from within audacity process which could be whitelistet or treated as “safe” from AV-Solutions.
So, in my opinion, Secunia is 100% right → This is a HIGHLY CRITICAL issue!
I’m not a programmer though, but I can’t believe it’s so hard to make Audacity looking for DLLs in Windows- and Programms-folder only?!
Greets, Claus
If someone has that access, then you have more to worry about than Audacity, and they would probably have found a way to put infected DLL’s in Windows system folders, even if you were not running with elevated privileges.
I believe the developers discussed this three times already. They are unlikely to change their mind.
I think you can find other applications that have the same “problem”, if this topic interests you.
Gale
Sorry if I’m wrong, but it seems to me, that some people here still think its about the rather small issue of Audacity loading DLLs from the Users local filesystem. This is not the case. Talking about DLLs on the users system, then you are right, this is not THAT much of an issue, since the DLLs have to get onto the users system first (even though an limitation to the really needed directories would be welcome even here).
The problem is, that the DLLs doesn’t even have to be on the users system, Audacity loads them from remote sources! If you look at my attached screenshot (previous post), you see that Audacity loads a DLL from an Network Share outside the users Network (a.k.a “The Internet”). So, an attacker could have his own code running on the victims PC with just 3 clicks and in the context of audacity, which most likely is treated as a secure app by the users AV-Solution.
As said before, I’m not an developer, but I can’t imagine it to be that hard, to limit the search-path for DLLs to the Audacity-Programm-folder (or whatever local directories are needed). At least remote folders should be an absolute nogo…
And please stop telling us, that other applications do that too. Even though this might be right for some badly supported apps, that doesn’t mean it should be that way!
I saw that network access was being used and it makes no difference to the arguments on either side, in my opinion. Network shares are assumed trusted, if it’s a local network at home.
If you are in a coffee shop, the local network should be assumed untrusted and sharing should be disabled.
No developers read Audacity Forum on a regular basis. If you wish to pursue this, please subscribe to the developers’ mailing list audacity-devel List Signup and Options and post there.
Gale
Well, thats the point → that is wrong. The Share on my Test was on a different network outside the Nat-Network of the Test-Client. You can simply test that on your own: Even if you have network sharing disabled, you should still be able to access this site:
\live.sysinternals.com\Tools
Disabling the Network Sharing on Windows has only effect on your own shares, not on shares on other machines or shares on public hosts.
I think the developers really should be pointed to this, but only when Steve and Gale confirm/agree, that this is more then just a minor issue. Because the Dev’s surely will listen much more to Steve/Gale, then to me 
Greets, Claus
That’s not the same as loading a dll.
If I try to open a file that is actually a dll and not a project, all that happens is that Audacity gives an error message saying that it can’t be opened because it’s not a valid project.
Yes, but as I have pointed out several times, when a user opens a project, Audacity loads several DLLs that are in the same folder as the project too. So, an attacker puts an Audacity project on a network share and makes Users open it. Next to the project is a malicious DLL. Audacity loads that DLL because it doesn’t check its location and bang, the user (victim) runs code of the attacker on his machine.
I can’t reproduce that.
What is your test-setup like?
I’m on Linux, but I’d be interested to see a proof of concept on any platform.
Well, it’s kind of obvious, that a DLL-Issue does not affect Linux
On Windows I have proven that its easy to embed a Link to a project which resides on a network share and make it possible for users to open the project with three clicks. I also provided evidence, that Audacity (on Windows) loads the DLLs from the remote Path. What I can’t deliver is a hacked DLL that opens Calc.exe for example, as said, I’m not a developer. But do we really want to wait until someone comes up with a working Zero Day exploit?
Please, just post to audacity-devel or do nothing. Certainly, stop posting here. The developers won’t see it here so you’re wasting your time and everyone else’s.
Gale
You’ve only shown evidence that Audacity can open a remote project, which is a world of difference from dynamically linking to a remote library.
If you can demonstrate that Audacity is vulnerable to DLL hijacking on a machine that is not already compromised, then the developers would probably be interested in that, but to my knowledge, no such evidence exists. If a user is tricked into downloading a malicious library and placing it in the library path, then for all practical purposes that is no different from tricking a user into downloading a trojan executable, and the only remedy for that is to educate people to adopt safety aware on-line practice, as outlined on our website: Redirecting to: https://www.audacityteam.org/FAQ#is-audacity-safe-to-download
As Gale wrote, the developers do not read this forum, so the most that can be achieved by continuing to post here is to spread fear, uncertainty and doubt among users, when what is actually required is information and education about safe practice.
If you have new information regarding the security of Audacity, please contact our developers directly.
And just to add, setting the network to “public” will do that and turn off network discovery.
Gale
Well, it sadly seems that I really wasted my time 
Two Persons and one Security Research Business couldn’t manage to make you see the danger for Audacity Users on Windows, so seems like they will stay at risk for a long time