DLLL HIJACKING Audacity 2.1.2

[waxcylinder]

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.

The workaround is quite simple - and is the same for all material availabel on the internet for download or cia email.

If you don't trust a user that sends you stuff (links, Audacity projects etc) then jolly-well don't open it

[steve]

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.

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

Again you are misrepresenting, or misunderstanding the nature of the risk. For applications that require dynamic linking, it is not possible to eliminate the risk of DLL hijacking. Even using absolute paths only, exactly the same exploit is possible by placing the malicious DLL in that location. DLL hijacking requires that the malicious DLL has been planted in the DLL search path, which is not the same as the "project load path". When loading a project, Audacity attempts to "read" the project - it does not attempt to "execute" the project. You have suggested that a DLL planted within a remote project may be loaded by Audacity, but have offered absolutely no evidence to substantiate that claim, and which as far as I can see, does not appear to be the case.

You also assert that this issue can not affect Linux, which is also untrue. Although Linux does not use DLLs, it does use dynamic linking to library files, and exactly the same risk exists IF a malicious library is placed in the library search path ahead of the genuine library file.

Also, as has been pointed out several times now, you are talking to the wrong people. This is the user support forum, not the developer's mailing list.

[Gale Andrews]

From http://seclists.org/fulldisclosure/2017 ... dacity.txt

The attacker can place a malicious dll named avformat-55.dll in the same folder
of an Audacity project file. Upon opening the project file Audacity will load
and execute the malicious code within its proccess context. The attack may be
carried out remotely by inducing the victim to open the project file from an
external storage device or a network file share.

I'm not set up yet to test remotely. The internet must obviously be "trusted", but it is the job of the system firewall to reject incoming data that is not the result of a request by the computer.

Many naive users would not be capable of loading projects from UNC paths, so the attacker would need to provide step by step instructions to the user, which "ought" to look highly suspicious to anyone.

Using 2.1.2 or 2.1.3 I can't even reproduce this on the basic level of a local folder. In folder S:\Dll test I have

avformat-55.dll
klklkl.aup
klklkl_data
lame_enc.dll
wpd_ci.dll

I open S:\Dll test\klklkl.aup. According to Process Explorer (View > Lower Pane View > DLLs) none of the DLLs in S:\Dll test are loaded in Audacity.

Is my methodology wrong? From what application does this screenshot come?




Gale

[colebantam]

Again you are misrepresenting, or misunderstanding the nature of the risk. For applications that require dynamic linking, it is not possible to eliminate the risk of DLL hijacking. Even using absolute paths only, exactly the same exploit is possible by placing the malicious DLL in that location. DLL hijacking requires that the malicious DLL has been planted in the DLL search path, which is not the same as the "project load path". When loading a project, Audacity attempts to "read" the project - it does not attempt to "execute" the project. You have suggested that a DLL planted within a remote project may be loaded by Audacity, but have offered absolutely no evidence to substantiate that claim, and which as far as I can see, does not appear to be the case.

You also assert that this issue can not affect Linux, which is also untrue. Although Linux does not use DLLs, it does use dynamic linking to library files, and exactly the same risk exists IF a malicious library is placed in the library search path ahead of the genuine library file.

Also, as has been pointed out several times now, you are talking to the wrong people. This is the user support forum, not the developer's mailing list.

Well, to me it seems that I'm the one who is misunderstood. You say I didn't deliver any evidence that Audacity loads DLLs from Remote Locations, but I did! Just look at the screenshot I attached in an earlier post, and you can clearly see that:
a. Audacity loads a project from a remote Destination (which isn't basically a problem).
b. Loads several DLLs into the Audacity Process that also reside on the Remote System!

So, its NOT about Audacity loading DLLs from the Users System, as I have already told several times now, its about Audacity loading DLLs from "The Internet"!!!

As I have said several times now, I'm not an developer, so I can't give you a full blown POC which opens CALC.exe or demonstrates the issue in any other manor, but the screenshot alone is prove that Audacity loads DLLs from places where it shouldn't. You can look at the screenshot and just see it black on white (well, with yellow marks )

You said, that the search-path for DLLs is NOT the Project-Path. Well I say, even though its not the same path, the DLL-Search-Path includes the Project-Path, and exactly that is the issue!

In regards to Linux: All my Reports belong to Windows only. I have no idea about if/how this affects Linux nor do I care

BTW: Maybe the problem why you all don't see the issue is, that on the screenshot the "remote" Address uses a private-ip-range. So let me describe the test-setup:
In the test there were two PCs involved:
A:) A physical PC that acted as the "Evil Internet Host". This PC had the 192.168.8.* Subnet.
B:) A virtual PC that acted as the victims PC. This PC was behind a NAT-Network with 10.0.2.* Subnet.
The 192* Net is UNTRUSTED to the Virtual-PC, so even it has a "private" IP-Range, it acts like a real Internet-Host to the Victim-PC. If that's the point where you all don't believe me, I can make a setup with an real public-IP, but it would need a lot of time to do that, and the result would be absolutely the same! Also, I have given you the sysinternal link (\\live.sysinternals.com\Tools), where you all can see, that a typical windows-pc loads external network-shares without any warnings.

[colebantam]

The internet must obviously be "trusted", but it is the job of the system firewall to reject incoming data that is not the result of a request by the computer.

No. The Network on which the testfiles resided was UNTRUSTED. And the files ARE requested by Audacity, so no reason for the firewall to discard them.

Many naive users would not be capable of loading projects from UNC paths, so the attacker would need to provide step by step instructions to the user, which "ought" to look highly suspicious to anyone.

As already written, a user only needs 3 clicks to open the project. No complicated instructions are needed. I don't want to give to much details in public, but I can tell you those steps in detail via PM.

Is my methodology wrong? From what application does this screenshot come?

I repeated the test with Process Explorer, and its the same result (see new Screenshot). The old Screenshot was from Process Monitor. I don't know why its different on your setup. Did you run Process Explorer with administrative privileges?
On the new screenshot you also see Audacity window with the Settings/Libraries Window, and it has Lame and FFMpeg enabled, even though none of them is installed on the "victim-pc".

[colebantam]

I guess I found out why the DLLs aren't loaded from the testdirectory on Gale's Test-Setup. I assume Gale has Lame and FFMpeg already configured in Audacity? Well, all advanced Audacity Users might have
I just copied the DLLs to the application folder and configured Audacity to use those DLLs. With this config, Audacity doesn't touch the DLLs from the remote path anymore
So, seems like the issue lies within the "automatic library configuration" of Audacity, and only users that haven't installed Lame/FFMpeg are affected, because in those cases Audacity looks for those DLLs in the Project-Path too.
Even though the problem is narrowed down now, there are still a lot of users affected I guess, because how many average Audacity-Users install Lame/FFMpeg too?

[cyrano]

I think you're wasting your time...

Not because this isn't a true vulnerability, but because even the Windows installer has the same kind of vulnerability, which MS has been ignoring for over 20 years. It's still being reported, at least once a month.

The downloads folder on Windows has special status. Certain dll's, residing in the download folder, can be called from anywhere on the system. So it is just a question of getting the user to download a dll with the right name and finding a way to execute it.

And now you know why Windows isn't very safe.

[steve]

I assume Gale has Lame and FFMpeg already configured in Audacity?

I've just tried on Windows 10 Home, placing LAME and FFmpeg into a project folder on the Desktop (which should be a 'safe' location).
Neither LAME or FFmpeg were installed, and Audacity was a fresh installation of Audacity 2.1.3 from: http://www.audacityteam.org/download/windows/

For each test I reset Audacity preferences to a clean install state.

Test 1:
Launch Audacity normally, then select and open the project via the normal "File > Open" command.
Neither LAME or FFmpeg were loaded.

Test 2:
Launch Audacity from the command line with the project specified as a command line argument.
The project opened.
Neither LAME or FFmpeg were loaded.

Test 3:
Same as Test 2, but then go into "Edit menu > Preferences > Libraries".
Neither LAME or FFmpeg are loaded.
Browse for the libraries in the project folder.
Both LAME and FFmpeg are found and loaded.
Note: this is not a bug - if the project is not known to be safe, this would be blind stupidity / ignorance.
If either of these libraries were malicious, the PC would now be considered compromised.
Close and restart Audacity (by any means).
LAME and FFmpeg are loaded (as expected).


Note that DLL Hijacking requires that the "fake" DLL is inserted into the DLL search path, earlier in the search order than the genuine DLL. An arbitrary project folder is not in the DLL search path unless specified in the audacity.cfg file (the user's 'preferences'), so I don't see how the DLLs would be loaded from a remote location unless the computer is already compromised. The tests results above appear to confirm this. However, if you have evidence to the contrary, please feel free to contact the Audacity developers regarding it.

[Gale Andrews]

I guess I found out why the DLLs aren't loaded from the testdirectory on Gale's Test-Setup. I assume Gale has Lame and FFMpeg already configured in Audacity?

No. I worked with a clean audacity.cfg and uninstalled LAME and FFmpeg first.

Gale

[Gale Andrews]

Maybe the problem why you all don't see the issue is, that on the screenshot the "remote" Address uses a private-ip-range. So let me describe the test-setup:
In the test there were two PCs involved:
A:) A physical PC that acted as the "Evil Internet Host". This PC had the 192.168.8.* Subnet.
B:) A virtual PC that acted as the victims PC. This PC was behind a NAT-Network with 10.0.2.* Subnet.
The 192* Net is UNTRUSTED to the Virtual-PC, so even it has a "private" IP-Range, it acts like a real Internet-Host to the Victim-PC. If that's the point where you all don't believe me, I can make a setup with an real public-IP, but it would need a lot of time to do that, and the result would be absolutely the same! Also, I have given you the sysinternal link (\\live.sysinternals.com\Tools), where you all can see, that a typical windows-pc loads external network-shares without any warnings.

Yes I noticed you were faking something by having a private IP range for what you call "the internet". I don't think this is a common setup so would probably not be regarded as a convincing demonstration. However because it isn't really the internet, I suppose it is possible that Audacity is looking for FFmpeg on the physical machine because it *is* the actual host computer.

On the new screenshot you also see Audacity window with the Settings/Libraries Window, and it has Lame and FFMpeg enabled, even though none of them is installed on the "victim-pc".

So press the "Suchen" buttons. What path does Audacity show you in the dialogues?

I suggest you disconnect the physical (attacker's) PC from the network, then Edit > Preferences..., click OK, and open Help > Show Log... . This will show you if Audacity can find LAME or FFmpeg. If it can, remove or uninstall LAME and FFmpeg from the locations indicated in the log. Repeat OK in Preferences and examining the log as necessary until Audacity can't find LAME or FFmpeg.

Quit Audacity then delete audacity.cfg.

Now reconnect the physical PC to the network and repeat your test, looking in the Log.

I've set up an FTP connection to my server (that is, the actual internet) as a network drive. It can't be done natively so needs third-party software. I'll post back when I have tested.


Gale