Attaching an example theme

Deleted: jollyroger.deskthemepack 108 KB

jollyroger.deskthemepack 108 KB Download

The changes made to the UI are interesting, and could potentially be used as a part of a targeted attack where UI spoofing is involved. However, I don't see how this could be used without the payload being transferred via another mechanism.

The one suspicious aspect was the [boot] section in the .theme file format. It looks like:

  [boot]
  SCRNSAVE.EXE=%WinDir%\System32\bubbles.scr

The SCRNSAVE.EXE parameter corresponds to https://msdn.microsoft.com/en-us/library/dd405477(v=vs.85).aspx . SCR files are Windows executables that are already in our supported extension list. I experimentally verified that this setting only considered .scr files as valid. I.e. Setting the filename to "foo.<some other extension>" doesn't cause the target file from being treated as a Windows executable unless the extension used is '.scr'.

Theme packs (.themepack etc.) are a slightly different beast. They are .cab files that contain a set of resources in addition to the .theme file. However, again, .scr files aren't supported in a themepack.

There used to be a vulnerability in 2013 that grabbed SCR files from the Internet via themes but it has been fixed:

https://www.verisign.com/en_IN/security-services/security-intelligence/vulnerability-reports/articles/index.xhtml?id=1040

Here is a real world example that uses .themepack files to carry malware:

http://pwc.blogs.com/cyber_security_updates/2014/12/festive-spearphishing-merry-christmas-from-an-apt-actor.html

In #7, the payload is sent via a DLL renamed to a .jpg file. The article doesn't explain how themepack activates this executable. It's quite likely that the method for activating the executable involves exploiting a vulnerability that's already fixed on Windows (I can't tell since the wrapper is missing).

Either way, if themepacks are reliable or frequent vectors (due to vulnerabilities or otherwise), then we may consider adding them to the list of file types. However, as it stands, we don't have evidence that this file type can be used to reliably plant malware on a user's system. I'll defer to the SafeBrowsing folks on how to proceed.

research@nightwatchcybersecurity.com: Thanks a lot for sharing this issue and the accompanying details.
asanka@: Thanks for the great analysis!

Based on #4 and #6, it is clear that the use of .theme files to run arbitrary binaries is no longer possible.

I'm investigating the .themepack files and will get back to this issue once I'm done.

For .THEMEPACK and .DESKTHEMEPACK files, it isn't possible to package an executable inside these files and then get it to execute via a .THEME file.
An attacker needs to get the user to download that file separately, which Chromium would block in the first place.
Therefore, marking it as WontFix.

What about the fact that it can change system settings such as wallpaper?

That isn't a dangerous operation since:
1. It only changes the wallpaper.
2. Windows opens a "Personalization" window showing the user that their appearance settings have changed and allow the user to change it back with one click.

For all Download Protection VRP bugs: removing label Restrict-View-Google and adding Restrict-View-SecurityTeam instead.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot