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 
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.
From http://seclists.org/fulldisclosure/2017/Jan/att-2/Advisory_-_Unsafe_DLL_in_Audacity.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
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.
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.
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.
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”.
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?
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.
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: Audacity ® | Download for 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.
No. I worked with a clean audacity.cfg and uninstalled LAME and FFmpeg first.
Gale
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.
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
With no installation of LAME or FFmpeg, and clean audacity.cfg for each test, I have now tested three setups.
- Loading a project from a Linux machine on my local network.
- Loading a project stored on my FTP server on the internet, where the server is a folder that appears on the computer as an unmapped “network location”. This was created using “Map Network Drive” then not mapping, but following the instructions “Connect to a Web site that you can use to store your documents and pictures”.
- Loading a project stored on my FTP server on the internet, where the server is a mapped network drive with a drive letter. This allows accessing the project by internet UNC path “\WINDOWS-10-PRO<ftp server name>\httpdocs\dll\tone.aup”
In all cases, the folder containing the project also contains lame_enc.dll and avformat-55.dll.
In short, none of the scenarios loaded lame_enc.dll or avformat-55.dll into audacity.exe. I tried opening the project from File > Open… in Audacity, executing the AUP file from its folder, and executing Audacity at the command-line by calling the UNC path to the AUP file (for cases 1 and 3).
Gale
As it seems like Gale and Steve are not able to reproduce the scenario so far, I decided to brake this up into two parts. First demonstrating that Audacity loads DLLs from the Project-Path, and keeping the Remote-Stuff for later when you both can reproduce this one. Honestly I’m super surprised that it didn’t work on Steve’s, because this works for me on a clean install of Windows 10 x64 (1703) with Audacity (and VBox Guest Addons) installed only, 100% every time I try. To demonstrate that I’m not dreaming, I captured a video showing all the steps.
And please don’t bother me gain with “but in this scenario, an attacker would have to place the DLLs on the victims machine first”. Yes, I know that. As said, its a simplified demonstration, and I’ll dig into the remote stuff once Gale and Steve can reproduce this (local) one.
I can’t reproduce that on Linux because Audacity has been built with dynamic loading disabled.
I’d expect (but not tested) those steps to ‘work’ on Windows because you have launched Audacity from the Desktop, making that the “working directory”, and you have placed the DLLs into that directory. Adding a file path parameter when launching Audacity does not set the working directory to that file path.
Sorry (for my poor english?), I don’t understand what you want to tell me with that sentence. Its seems like that one of your sentences denies the other one. Because one line says “because you have launched Audacity from the Desktop, making that the ‘working directory’” and then you write something that seems to tell the opposite “Adding a file path parameter when launching Audacity does not set the working directory to that file path”. I’m confused…
Using the steps (the shortcut to Audacity on the Desktop is not a required step), Audacity loads the three av* files, but not lame_enc.dll. The log shows Audacity does not see lame_enc.dll on the Desktop, only C:\WINDOWS\SYSTEM32\lame_enc.dll, which does not load because it does not have sufficient symbols. Please post the Audacity log (Help > Show Log…) so we can see where your lame_enc.dll is being loaded from.
Arbitrary DLL’s such as twain_32.dll on the Desktop are not loaded.
The av* files are only loaded if I launch Audacity by double-clicking the AUP file.
The av* files are not loaded if I execute Audacity from wherever Audacity is, and then open the project, unless of course I put the av* files in the directory where Audacity is, in which case there is no need for the AUP file to be present to load the DLL’s. This is the difference that Steve explained to you.
I see that if I put lame_enc.dll in the directory where Audacity is, LAME does load, as expected.
Gale
- The desktop shortcut to audacity is just used for convenience, of course I could have started it from the start menu too.
- On typical systems, there is no file “C:\WINDOWS\SYSTEM32\lame_enc.dll”. If you delete (or temporarily rename) it, the “lame_enc.dll” from desktop should be loaded.
Here’s the Logfile content:
18:44:58: Audacity 2.1.3
18:44:58: Trying to load FFmpeg libraries…
18:44:58: Trying to load FFmpeg libraries from system paths. File name is ‘avformat-55.dll’.
18:44:58: Looking up PATH environment variable…
18:44:58: PATH = ‘C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Users\xxxxxxx\AppData\Local\Microsoft\WindowsApps;’
18:44:58: Checking that ‘’ is in PATH…
18:44:58: FFmpeg directory is in PATH.
18:44:58: Checking for monolithic avformat from ‘avformat-55.dll’.
18:44:58: Fehler: Kann Symbol ‘avutil_version’ in der dynamischen Bibliothek nicht finden (Fehler 127: die angegebene Prozedur wurde nicht gefunden.)
18:44:58: Fehler: Kann Symbol ‘avcodec_version’ in der dynamischen Bibliothek nicht finden (Fehler 127: die angegebene Prozedur wurde nicht gefunden.)
18:44:58: avformat not monolithic
18:44:58: Loading avutil from ‘avutil-52.dll’.
18:44:58: Loading avcodec from ‘avcodec-55.dll’.
18:44:58: Loading avformat from ‘avformat-55.dll’.
18:44:59: Actual avutil path C:\Users\xxxxxxx\Desktop\avutil-52.dll
18:44:59: Actual avcodec path C:\Users\xxxxxxx\Desktop\avcodec-55.dll
18:44:59: Actual avformat path C:\Users\xxxxxxx\Desktop\avformat-55.dll
18:44:59: Importing symbols…
18:44:59: All symbols loaded successfully. Initializing the library.
18:44:59: Retrieving FFmpeg library version numbers:
18:44:59: AVCodec version 0x373466 - 55.52.102 (built against 0x373466 - 55.52.102)
18:44:59: AVFormat version 0x372164 - 55.33.100 (built against 0x372164 - 55.33.100)
18:44:59: AVUtil version 0x344264 - 52.66.100 (built against 0x344264 - 52.66.100)
18:44:59: FFmpeg libraries loaded successfully.
18:46:45: Attempting to load LAME from system search paths
18:46:45: Loading LAME from lame_enc.dll
18:46:45: Actual LAME path C:\Users\xxxxxxx\Desktop\lame_enc.dll
18:46:45: LAME library successfully loaded
I was wondering why it took so much longer for Lame to load than FFMpeg in the Logfile. I just realized, that Lame only loads when opening the Settings-Window. But FFMpeg DLLs are loaded immediately after opening the project without the need for any other user-input.
It’s FFmpeg, not FFMpeg.
LAME will attempt to load when you try to export an MP3 file, so the user does not need to open Preferences before exporting MP3.
If you look in one of your monitoring tools, you will also see that lame_enc.dll is only loaded while MP3 export is in progress, after which it is unloaded.
Gale
So, Gale, can you confirm now, that both DLLs (Lame and FFmpeg) are loaded from the project-path when opening a project-file from Explorer/Desktop on your test-setup?
(with no lame_enc.dll existing in system32-folder)
I don’t have “C:\WINDOWS\SYSTEM32\lame_enc.dll”, but the referenced file is in C:\Windows\SysWOW64.
As you can see by the log below when that lame_enc.dll exists, Audacity makes no attempt to load LAME from the Desktop:
20:26:00: Attempting to load LAME from system search paths
20:26:00: Loading LAME from lame_enc.dll
20:26:00: Actual LAME path C:\WINDOWS\SYSTEM32\lame_enc.dll
20:26:00: Error: Couldn't find symbol 'get_lame_version' in a dynamic library (error 127: the specified procedure could not be found.)
20:26:00: Error: Couldn't find symbol 'lame_encode_buffer' in a dynamic library (error 127: the specified procedure could not be found.)
20:26:00: Error: Couldn't find symbol 'lame_set_in_samplerate' in a dynamic library (error 127: the specified procedure could not be found.)
[...]
20:26:00: Failed to find a required symbol in the LAME library.
20:26:00: Attempting to load LAME from builtin path
20:26:00: LAME registry key exists.
20:26:00: Library path is: C:\Program Files (x86)\Lame For Audacity
20:26:00: Loading LAME from C:\Program Files (x86)\Lame For Audacity\lame_enc.dll
20:26:00: Error: Failed to load shared library 'C:\Program Files (x86)\Lame For Audacity\lame_enc.dll' (error 126: the specified module could not be found.)
20:26:00: load failed
20:26:00: (Maybe) ask user for library
20:26:00: Failed to locate LAME library
So that looks like a bug there. I would expect Audacity to find lame_enc.dll on the Desktop rather than give up.
Yes, Audacity loads lame_enc.dll from the Desktop if C:\Windows\SysWOW64\lame_enc.dll is removed.
None of this gets us anywhere we have not visited before, does it?
Gale