DLLL HIJACKING Audacity 2.1.2

[Filipe]

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).

[Gale Andrews]

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

[Filipe]

Sorry for my mistake, the vulnerable version is 2.1.2 and not 0.10.1.

[colebantam]

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 ... dacity.txt

Secunia Advisory:
https://secuniaresearch.flexerasoftware ... ies/74570/

I think, by reading the Advisories the impact of that issue gets much clearer...

Greets, Claus

[steve]

I just came across this via Secunia, where this issue is considered "Highly Critical".

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: http://www.audacityteam.org/download/on ... wnloading/

[colebantam]

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.

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

[Gale Andrews]

someone who's able to manipulate those DLLs to run his own code

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

[colebantam]

someone who's able to manipulate those DLLs to run his own code

If someone has that access, then you have more to worry about than Audacity

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!

[Gale Andrews]

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.

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 https://lists.sourceforge.net/lists/lis ... city-devel and post there.


Gale

[colebantam]

Network shares are assumed trusted, if it's a local network at home

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