Has Cicada's hack been corrected?

[InTheWings]

Do Note - and this is the most IMPORTANT part: The only people who will suffer are the ones who have trusted the VideoLan brand and are actively looking for the VLC app for their media player needs. They will either get a suspect installer, or if they get the official installer, they will never know if their installation has been hacked by a state/non-state actor.

They will suspect nothing.
1 - Circada & such target individuals using Portable versions, i.e. "Extracted" packages.
2 - Supposing this is installer repackaged, you're expecting from a user *which accepts to install any crap from random people* to check signatures ??

All your changes will be useless as they can ship a modified exe (that's just a little more effort), or just switch to another application.

The universal fix is easy: don't --please stay polite-- run software from untrusted sources.

Not even mentioning the social engineering by just asking the target to "ignore warnings"

[dont bug]

I am reading this post as a one level progress from your early stance - and it seems you are acknowledging that if the whitelisting process is enabled for the binary, then you have solved one set of problem, although the issue of unofficial binaries, and of users unwilling to do the signature check remains.

The thought experiment wasn't as hard to do, so wonder why you had to be forced to respond to it after repeated pointed messages. (Although one may argue, that you have still refused to explicitly acknowledge it despite repeated attempts to focus your attention on the ONE aspect being asked about, but then one must give some benefit of doubt).

As to the points you mentioned:

1 - Circada & such target individuals using Portable versions, i.e. "Extracted" packages.

Kindly read up on the definition and explanation of Strawman argument before talking about patched/modified/unofficial/hacked/portable VLC apps.
EVERYONE knows that using apps from unofficial places carry various forms of risks. Give some credit to users that they are intelligent enough to know that. If you still have doubts, there should be an attempt to educate people instead of Nero-ish washing off of hands.

Also, it is extremely dubious of you to claim that these state/non-state actors have TARGETED Portable versions, and by corollary making the false implication that the official installation is never at risk and hence never targeted, where the truth is that a state sponsored hacker could have very well placed a malicious file inside an official installation WITHOUT modifying ANY other file from the OFFICIAL Installation and the user would never know in the current scheme of things. Please do not try such diversionary tactics at least on your own official forum where it will paint the organisation in a bad light on record.

Had this been true, you would have ensured that the examples that claimed otherwise like the BleepingComputer link were forced to send out a retraction. Fact is, you know it is true, as that is how the binary is currently coded and side-loads anything that a non-state/state sponsored actor might have placed in the folder.

2 - Supposing this is installer repackaged, you're expecting from a user *which accepts to install any crap from random people* to check signatures ??

At least then we have a way of telling people to check if they have a compromised binary or if they have a binary which is protected from side-loading any malicious DLLs. How it gets implemented in the long term by people, defender apps, policies, processes is a secondary discussion, but if there is such an easy mechanism available, one can at least make a pitch that the official binary from the official site cannot load unauthorized / non-whitelisted and potentially malicious DLLs. Given that, one can then make a case that the official site should not be banned because it is aiding in the solution to the problem, preventing people from having to resort to downloading --politically incorrect term-- from unofficial sources. AS OF NOW, as things stand, users do not even have an option of checking the VLC binary signature and taking a call if they can trust the installation, or should they just reduce some (of the admittedly many) failure points and just nuke the installation.

You may kindly stop the whataboutery about 'social engineering', brain-fade, suicidal and maniacal behaviour - all of that and more can happen in the world, but all global problems, or even the problems in your own city and street need not be solved before you do some spring cleaning inside your own house.

[InTheWings]

Also, it is extremely dubious of you to claim that these state/non-state actors have TARGETED Portable versions, and by corollary making the false implication that the official installation is never at risk and hence never targeted, where the truth is that a state sponsored hacker could have very well placed a malicious file inside an official installation WITHOUT modifying ANY other file from the OFFICIAL Installation and the user would never know in the current scheme of things. Please do not try such diversionary tactics at least on your own official forum where it will paint the organisation in a bad light on record.

Again,

There's no such "official installation WITHOUT modifying ANY other file from the OFFICIAL Installation" that would not need to modify the installer or archive, so, its own signature.
I'm not aware of any "official installation" that ships each file individually or as a whole directory without being an archive with checksum or signature.

If there was a malicious file inside the official installer, meaning someone has infiltrated the whole build and signature process, then asking the packed content to check itself is already too late.

If you use an extracted package directly, then we can do nothing for you.
If you use an archive not from the official release servers or do not check the signature/checksum then we can do nothing for you.

[dont bug]

I think after the first few messages, the dev-team has forgotten that a non-state/state sponsored entity is at play.

No one said that the infection was coming with the installer, but rather, given the architecture, if the Installation is infected, no one has a mechanism to check and confirm leading to lack of trust on the application, and the one-size-fit-all solution of nuking it, and using an alternative app.

For the purpose of clarifying the scenario:
1. Official installer downloaded from official website and installed.
2. State sponsored actor hacks into the device and places a malicious DLL (malware loader) in the paths that will be scanned by the UNMODIFIED OFFICIAL Executable when it starts. No other file/folder is modified, including the VLC binary, and the machine is now left alone.
3. Unsuspecting user runs the VLC binary
4. Malicious DLL is side-loaded by the VLC binary which in turns loads and executes the actual malware - The first stage will be seen by the OS as VLC app running some code.

Even if users were made aware that VLC app has been known to behave in such a manner, they have no mechanism of knowing which is the infected DLL and which is a valid third party plugin. The app does not have a whitelisting capability, and if it had that, all a user needed to do was to cross check the signature/hash of the executable and they would know if the exe is safe or has the risk of running any unknown and potentially malicious DLL.

Please re-read the thread with this clarification and then respond.

[Rémi Denis-Courmont]

You're not making sense.

VLC releases are hashed and digitally signed. We can't force people to verify the signature, so as InTheWings already noted, there's nothing we can do in that case. By the time the user runs the unchecked vlc.exe, it's already too late to check anything.

Whether you like it or not, the system has to provide for integrity of applications. An application cannot check itself.

The automatic update does verify the signature though, but that only works if the first installation was checked manually, and if the system is not subjected to Evil Maid-type attacks

[dont bug]

By the time the user runs the unchecked vlc.exe, it's already too late to check anything.

I don't know why it is so confusing for you - The application is not supposed to check itself : At execution, the binary is supposed to check the DLLs it is loading. And NO - it is never too late to 'check for anything' before executing the DLL code.

Visual Studio and the likes have already implemented it through the manifest file feature, and do take the trouble of reading up on why the NSRL database was created. No one spends hundreds of thousands of dollars to implement a feature just on a whim.

Whether you like it or not, the system has to provide for integrity of applications.

If every application development team behaved like you waited for all the global problems to be resolved before doing their bit to fix their own house before pointing fingers at others, the world would be a very sad place. Thankfully, you seem to be in the minority and most developers take their responsibility a bit more seriously.
As of now, as far as the system is concerned, the VLC binary is unmodified. What it does at runtime is a VLC problem - wonder what will it take to instill some amount of pride and ownership into your team to stand behind your code.

We can't force people to verify the signature

No one is asking you to force any user to do anything - all people are asking you to provide a mechanism by which users can satisfy themselves that VLC is not going to become a malware loader. After that, your role is in educating the users to check the signatures and not wringing your hands and saying that users will not do anything, so why bother providing an option.

The point in question was whether we can create a mechanism to help VLC regain the trust of users, or if the users are better off being protected by the half hearted attempts of the Nanny-States/ in getting rid of VLC completely where possible.

[InTheWings]

all a user needed to do was to cross check the signature/hash of the executable and they would know if the exe is safe or has the risk of running any unknown and potentially malicious DLL.

Check which signature ? we do not provide internal exe signatures.

I'll repeat that we attest for the whole package, just like any other release mechanism. We check the integrity of the whole payload. If you break the seal and taint it, there's nothing we can do.

VLC also uses system DLL and some others for dvdcss features, java bluray, ...
Since DLL loads from current directory first,
Supposing we implement such late flawed check and useless feature, and are you also going to ask apps to check signatures for the full system DLLs ? ... which it can't be cause running its own code would also require loading DLLs that you want to check.

[dont bug]

Check which signature ? we do not provide internal exe signatures.

Did you even read the point wise scenario that was laid out to aid your understanding? It was broken into short sentences and points so as to not confuse your limited comprehension skills. Maybe the person who gave you a pass mark on your O-level English language skills/comprehension needs to do some serious introspection.

In each message, we have asked about the signature to assert the integrity of the VLC executable/the app loading the DLLs, and not the installer.

If you break the seal and taint it, there's nothing we can do.

When you write If you break : were you under the impression that users are in the habit of finding a malicious DLL, putting it into the folder and then crying wolf? How else are the users 'tainting' it? I thought you were being obtuse but this is a whole new level of ignorance. It seems you are purposefully trying to ignore that a state/non-state sponsored agent is at play without knowledge/concurrence of the user who were foolish enough to trust VideoLan/VLC.

there's nothing we can do

Yeah you can - in fact your team already said that if you had to do anything on the solution lines, it will take a lot of effort and no one is paying you/enough to do that. It's just that you don't want to.
Thing is, you definitely could have done a lot apart from being a cry-baby on social media platforms, but only if you had any willingness to do it. It appears that you are happy being known as a malware enabler : Guess different organizations put different value on being trusted, and you unfortunately seem to be are the worse end of the spectrum.

What you are basically saying that if a non-state/state sponsored actor may/could put a malicious file at some point on the system, executing the VLC binary has the potential to put the user at risk - also, the VideoLan team has not and will not make any attempts to ensure that users can confirm if their installations are still pristine or they have been hacked at some point. So, the only thing that can be done by pragmatic users is to steer clear of something that has the potential to wreak havoc on the system/network. No wonder many organizations are progressively banning VLC from all their systems. You have worked hard to gain that ignominy.

VLC also uses system DLL and some others for dvdcss features, java bluray, ...
Since DLL loads from current directory first,

And you cannot maintain a whitelist of all DLLs that you need to use?? How ignorant can a codeset be that it cannot predict in advance what libraries it needs to load? Also, stop worrying about files/DLLs that VLC does not use/ run code of. Someone else will take care of it - you neither need to solve world poverty, apartheid and other global issues, nor do you need to talk about it here.

Please re-read the point wise scenario laid out before you respond and advertise your perverse motivations in trying not to solve the issue.

Once you have read the scenario - read the following and comprehend it. If not, before making comments that show you in poor light, ask questions. No question is too stupid, although I suspect you can prove the adage wrong.

Single Question - Respond to only this:
Why do you think this will not work, and/or do you have a better solution without crying about problems not under your direct control?
1. Maintain an NSRL kind of central whitelist of libraries that can be run by the VLC binary
2. AND/OR Whitelist libraries that will be loaded by the binary by using a manifest file that includes the hash of the library to be loaded
3. Publish the hash/signatures of the VLC binary that any user can reconfirm at any point to ensure that the functionality above will be implemented.

[InTheWings]

Sorry. No english understand