What's the working of malicious javascripts and how can it be mitigated?
I am wondering how malware gets served through Javascript. I've noticed a few illegitimate pop-ups while visiting some financial websites. I wonder how malware exploits work against the application and what an application can do to at least inform it's users that the popup is not from the website, it's from the malware.
- Drive-by downloads are typical malware vectors for malicious JavaScript to get binaries onto a user's machine. The JS just starts a request of a malware binary that responds with Content-disposition:attachment which prompts the user to download it.
- The JS can continue this even if the user cancels, effectively making the user's browser unusable (they may not know how to kill a process manually) and often attempts to make the download look like antivirus software.
- Some proportion of users will accept the download just to get their browser back, and then the malware vendor just has to wait for the binary to be run.
- The core problem with viruses and malware is that the OS confuses the current user with the programs they run. When I run Solitaire, that process has the ability to edit every file that I can from the command line or Windowing system. That should not be the case.
There's no reason why Solitaire or a screensaver that you download from the web needs access to your tax files, so you can use a combination of cues to figure out what privileges it needs Did the user grant authority via a file dialog or some other OS-mediated designation method like drag-n-drop? ("Secure Interaction Design") explains a variety of ways to infer grants of authority by looking at the way they interact with a user-interface.
Is the file in a directory "owned" by the application by virtue of being created during the installation of the application binary?
Is the file a common system resource like a DLL or shared library?
Other privileges can be similarly granted based on user designation or simple rules. Most operating systems and applications were not written with this in mind, so systems like Polaris from HP labs shows how to allow apps to run with less than current-user permissions on Windows. People often forget that POLA means two things at the same time. Not only must you prevent the application from having more authority than it needs to do the user's job, but also you must ensure that the application has enough authority to do that user's job. Granting too much authority is why there are viruses that hijack applications. Granting too little authority means that the application is useless, like a spreadsheet program in a web browser sandbox that cannot save the result on your hard disk. Polaris gives neither too much nor too little authority: while a polarized application cannot in general corrupt or infect files on your computer, the application can indeed store information to any file that the user explicitly specifies by either double-clicking on the file or by selecting the file in a dialog box. Thus, the Polaris system dynamically adjusts the authority of the application to do what the user wants.
Unlike static sandboxes, Polaris does not appreciably affect the user experience. In fact, one HP executive used a pre-Alpha version of Polaris for three days without knowing it was on his machine. Polaris does its magic without changing applications or the operating system. Nor does it rely on intercepting system calls. Instead, when users "Polarise" an application, the "Polarizer" creates a restricted user account for that application. When users launch the application, either explicitly via the shortcut the Polarizer created or implicitly by opening a file of the appropriate type, Polaris uses a variant of the Windows runAs facility to open the program in its account. The bulk of the Polaris software hides this fact from the user.