Oh, it does You have confirmed that Audacity loads DLLs from the project path, which is definitely a security issue. We have also learned, that Lame and FFmpeg must not be installed to make that Attack work. And we have learned how to easily demonstrate it (not needing sysinternal tools anymore). So we have made some huge progress compared to my first posts…
Time to go the next step and demonstrate the remote version of this issue now. Because I don’t want to give a demonstration of this in public, I’ll send the video to Gale (PM) directly…
Sorry, but all I see is more FUD.
Yes it is known that there is a potential risk if a malicious DLL is placed in the library load path. We can fix that by ripping out support for WMA, AAC, AC3 and other closed source formats. We are not going to do that. The application’s working directory is a standard location in the library search path - if you have a problem with that, take it up with Microsoft.
If you, or anyone else, can present evidence that a real risk exists that does not depend on the machine already being compromised, or dangerous actions by the user (such as running a trojan), then I’m sure that the Audacity developers will want to know. So far you have comprehensively failed to do so, and I have spent a lot of time on this topic.
We would appreciate you not misleading our users. We have confirmed that Audacity does NOT load DLLs from the project path, because executing Audacity from Program Files then opening the project does not load the DLL’s.
It would of course be a possibility to prevent loading of DLLs from the current working directory unless these were specific paths such as the path to audacity.exe. But the developers have already rejected that idea three times, on the grounds that the attacker then simply has to place his malicious DLLs in the executable’s directory instead, or do anything else that his control of the computer allows.
This is true, but who opens projects from within an app? I guess most users open a project by clicking the project in Filemanager, and thus leads to loading the DLL, as you have confirmed!
This is,because you all still stick to the idea, that an attacker needs to have access to the victims PC, which is not necessary, as I have demonstrated several times now, that audacity loads those DLLs directly from UNC-Paths (aka network shares). All the developers would have to do, is prevent Audacity from loading DLLs from the project-path! This should be a thing of a couple of minutes of coding (of course I’m not a developer, as I have told many times now).
Don’t tell me im frightening Users without any reason. I didn’t make that issue, I was not the first who warned about it, but of course the initial reporter, Secunia and me are all wrong…
Or the user does not exercise reasonable safety precautions. We cannot protect against unsafe practice.
So what happens if I put a virus / trojan on a remote share and tell you to connect to the server and double click on that file? What relevance is Audacity in this scenario?
I have demonstrated in a video, that 3 clicks are enough to (potentially) infect people. You have written, that you couldn’t do it with your strange 3rd party software. So, which demonstration is more relevant to average users? The one that involved only default software and showcases the potential danger on users, or the one that uses 3rd party software and says everything is fine?
There’s nothing more I can do, because the next step would be to “infect” people just to deliver prove it can be done, and even then would the people here say, that its the users fault, because they did “unsecure” things. This ist silly and I won’t post anything more to that thread, because its simply a waste of precious time.
Without third-party software, it is not possible on Windows to map a real site on the internet as a network drive that has a drive letter. You can research it if you do not believe me.
As I wrote, I also connected to my FTP site on the internet as a shared desktop folder. That method does not require any third-party software. Using that method too, the DLL’s in the same folder as the project did not load.
Further I demonstrated that Audacity does not load DLL’s from a Linux computer on my own private network.
I have seen that you can connect to sysinternals (or Microsoft) open sites using UNC paths. Given those sites cannot be uploaded to I cannot test downloading Audacity projects from there.
I have seen your video about connecting to (what looks like) a site on the internet. That does not convince me. We cannot see what is in the .LNK file, and we see in Explorer only the AUP file, not the the ̠data folder of the project or the DLLs that Audacity appears to load from the same IP address according to the log. You should be aware that Audacity won’t open projects without a ̠data folder in the same directory as the AUP file.
Are you still using a Virtual Machine as indicated by your Taskbar? If so that could be what is causing the DLL’s to load, just as in your previous example where you claimed to be connecting to the internet, but were not.
In sum you would need to do far better than that. You would need to give step by step instructions, without a virtual machine, as to how I would set this up on my server, and explain how you got Audacity to load a project without a data folder and why the DLL’s that Audacity loads are hidden from Explorer.
If you provide that to me or Steve we will look at it as and when time permits given our many other Audacity duties. Or you can write to audacity-devel as was suggested long ago and try to privately engage a developer in your quest. A video like the one you just sent me by Private Message won’t convince a developer.
When launching Audacity by executing the AUP file on the internet or local network and Audacity fails to load the DLLs in the project folder, the current working directory is C:\Windows\System32.
You have confirmed that Audacity loads DLLs from the project path, which is definitely a security issue. We have also learned, that Lame and FFmpeg must not be installed to make that Attack work. And we have learned how to easily demonstrate it (not needing sysinternal tools anymore). So we have made some huge progress compared to my first posts…