Security Week 40: the ‘not-really-a-vulnerability’ in WinRAR, an ancient bug in Firefox, and the oops!-update by Microsoft

I wonder what will happen when there are no more infosec problems. Will our Threatpost.com news blog convert to a digest of kitty cats? Is this bright future feasible at

I wonder what will happen when there are no more infosec problems. Will our Threatpost.com news blog convert to a digest of kitty cats? Is this bright future feasible at all? Well, it is, considering the pace of evolution in the IT industry. Right now it is still trying to overcome its teething problems and once it has, the bright new day will come.

I believe that someday we will see more mature, responsible approaches to information security. Yet, the Internet is, anyways, a virtual model of a real world which has it all: secluded geniuses who are about to invent their own Google in the garage, major corporations who fight their cause, ordinary folks, and, finally, those who want to take advantage of all of them. There are ways to make the cybercriminals’ lives harder, but can we get rid of them for good?

One curious event invoked this thought in me: the most popular news from last week (the one about bugs in Firefox) did not have to do anything with information security – well, relatively nothing. However, Threatpost’s readers paid most attention to this news (our editors should try funny kitties, really). The second news covers a vulnerability, which is kind of not there. The third news of the week is about Microsoft’s update, which did nothing and then disappeared.

Well, seems like nothing happened this week – so now let’s talk about differences between real and theoretical threats. As always, the rules of the road: every week our Threatpost‘s editorial chooses three most popular news, which I then ruthlessly comment. Check other editions of Security Week here.

0-day (pseudo)vulnerability in self-extracting WinRAR archives

News. Research. RARLAB’s feedback.

An Iranian researcher, Mohammed Reza Espargham, found a vulnerability in WinRAR – not in the software itself but in self-extracting archives which could be created by the precedent. Sounds very critical, at first. By using an inherent archiver feature, one could enable arbitrary HTML code execution when extracting, which could download and run any malware from the Internet – with the contents of the archive absolutely clean and harmless. The vulnerable function is capable of displaying a text on screen, as well as accepting and processing HTML.

WinRAR’s developers don’t agree with this news. To get their point, one should just simplify the description of the bug to “a user may get in trouble when downloading and running some weird executable.” Did I miss anything? This is a fundamental and unpatchable conceptual vulnerability of computers: they execute ALL codes run on them. WinRAR team proves their point citing a ‘proof of concept” for another ‘zero-day’: the contents of the self-extracting archives can be set to run automatically, without the user’s consent. FATALITY!

Here come the kitties!

Both sides have fair points. Sometimes, non-standard uses of standard tools may be detrimental to the security of the product. An encryption technology could be used both to protect the personal data and to encrypt the user’ data by ransomware. So we have Code Pear-colored (with a hint of chartreuse) for this security event.

However, there is one thing. WinRAR is an extremely popular piece of software and, unlike other members of this club, does not require constant update. It’s not the like of a browser, which is updated every month, it just keeps working and that’s it. A couple of years ago we published a report on a survey which was meant to demonstrate how often users update vulnerable software. Well, rarely do they update at all: it took seven solid weeks for 30% of users to convert to the newer Java.

Our research encompassed a critical vulnerability in WinRAR 3.71, with several earlier bugs. We never intended to track this bug as it was hardly exploitable, but as we checked the data on updates, we were stricken by the fact that five years later the vulnerable version of WinRAR was functioning on tens of thousands of PCs, still unpatched.Why would anyone patch it, after all? The archiver does not have an auto-update process, anyways. While we have Java, Flash and browsers, cybercriminals would not spend a minute of their time hacking such long-standing, venerable programs. But what if their usual targets become less hackable?

The adventures of Windows’ hollow update

News. Discussion on the Microsoft’s forum, uncovering some details.

On September 30, without prior notice, Windows Update Center decided to speak mumbo-jumbo to its users.

And I mean, literally: gYxseNjwafVPfgsoHnzLblmmAxZUiOnGcchqEAEwjyxwjUIfpXfJQcdLapTmFaqHGCFsdvpLarmPJLOZYMEILGNIPwNOgEazuBVJcyVjBRL

Those rare species of a user who really look at the updates they get via Windows Update Center, predictably, blew the whistle: some weird stuff appeared, tried to install itself, failed, and then disappeared. Later, it was found out that a similar thing happened on Aug 20.

Security Week 40: suspicious Windows7 update

Later, Microsoft’s official spokesperson admitted that it was a test update, which was distributed to users by mistake. So everyone can sit back and relax. Was there any reason to worry? It was, in fact: should Windows update system be compromised, it would result in the global digital apocalypse worthy of Ronald Emmerich.

Imagine a culprit distributes an arbitrary code to millions of users and runs it without their knowledge. Fortunately, it’s hardly feasible: we have digital signatures and encryption in place. One of our earlier Security Week digests I covered an unlikely hack of WSUS that affirms that the system cannot be fundamentally destroyed.

At least we can hope it is so.

A 14-year old memory-devouring bug patched in Firefox

News. Blog post commissioned by Adblock Plus, the main victim of the bug. The bug itself.

Security Week 40: Firefox bug fixed - screenshot

In a nutshell: Firefox consumes a lot of memory. With the release of version 41, it stopped being that voracious, especially if you have the AdBlock Plus extension installed. The root of the problem was in a way the adware blocker and the browser interacted with each other. By processing an adware blocking method with CSS, the browser reserved too much memory (up to 2 GB!).

Originally this bug appeared on April 27, 2001, in a pre-release 0.9.3 version. That year marked the appearance of the first version of Mac OS X, Windows XP, and the very first iPod; it was the year when SATA and USB 2.0 premiered on the market; it was the year when the V.92 modem protocol was out, and Microsoft finally killed off the Paper Clip. Heck of a year, heh?

The bug is quite harmless. I wonder whether 10 of the 14 years that the bug was in place were spent with Firefox and Adblock’s developers arguing over who was to blame. Real critical vulnerabilities are usually promptly patched, right?

Wrong! In my quest for ancient bugs, I stumbled on this one: Red Hat (and some other) distributions do not check the authenticity of upgrades and other installed software. In theory, this helps to gain control over the compromised system if it were installed or updated from a malicious mirror. The bug has been around since January 30, 1999! It was not even about mirrors, it was about infected diskettes! It was fixed (and, probably, not entirely) only in August 2014.

Security week 40: It's been 84 years since...

Okay, okay, this is a kind of a ‘bug’ we have referenced above with regards to WinRAR SFX. It’s not even a bug as such, it’s an assumption that ‘if you drop your laptop into a campfire, it will burn.” I doubt there was intention to fix it, in the first place – likely the stakeholders kept it in a bug tracker to spark occasional discussions about the security in Linux. Does this bug serve the proof that the Linux security failed? No, of course, not.

I would go as far as suggest that prompt patches to all vulnerabilities alone cannot guarantee security of your data. Here I found out that software developers spend, on average, up to 100-120 days on patching. We would love it to happen faster, of course, but does it imply that all unpatched vulnerabilities are exploited? No. There are so many attacks and potential bugs, and any attempt to address all vulnerabilities will result only in white noise.

By the way, some time ago there was a Threat Indicator on Kaspersky Lab’s website. It allowed you to assess the generic level of security – all at once. Then it turned into some version of the Doomsday clock; it looked quite impressive, but it stopped serving an adequate means of assessing threat realities, and was taken down.

Now every person or company has their own level of security, and it depends on a number of variables: overall ‘hackability’, the value of the data in question, and how seriously one takes their security.

https://twitter.com/DwightVJackson/status/646340189657305088

What else happened:

This week was quite fruitful in terms of news, but nothing special, really.

Another vulnerability was discovered in Android’s Stagefright engine. The first of this kind, disclosed earlier this summer, was exploited via MMS; the newer bug runs an arbitrary code if a user opens a specially crafted page in a browser. Now, the problem lies within the way the library processes a multimedia file’s metadata.

101 bugs were fixed in Mac OS X (El Capitan). Also, another lock screen bypass bug (via Siri) was patched in iOS 9.0.2. (Hey Siri, DROP TABLE).

A long quest for embeddings in TrueCrypt resulted in nothing. But in the process the researchers found a bug, which, nevertheless, is not able to decrypt encrypted data. However, TrueCrypt might be used to remotely escalate privileges. The flaw was fixed in the TrueCrypt spin-off, VeraCrypt.

Bebe

A non-resident dangerous virus. It infects .COM files in the current catalogue. It increases the size of a file to reach a multiple of a paragraph, then copies itself to the end of the file and alters the first 14 bytes (PUSH AX;…; JMP FAR Loc_Virus). Being non-resident, it creates a resident program. It copies a part of its body into the interrupt vector table at 0000:01CE and sets the 1Ch interruption (timer). In a matter of time a message is displayed on the screen:

VIRUS!

Skagi ‘bebe’

As soon as the user inputs ‘bebe’ from the keyboard, the virus responds: “Fig Tebe!” (“Screw you!” in Russian), which evidently hints the country of origin. There is a mistake in the code: it does not restore DTA. This may result in laggy PC. Another flaw: the virus does not take into account the pipeline in Intel 80×86 processors and modifies the command next after the current one and, as a result, is operational only on outdated IBM PC models. Besides the aforementioned text, it includes a *.COM line.

Computer viruses in MS-DOS, Eugene Kaspersky, 1992

Quoted from “Computer viruses in MS-DOS” by Eugene Kaspersky, 1992. Page 60.

Disclaimer: this column reflects only the personal opinion of the author. It may coincide with Kaspersky Lab position, or it may not. Depends on luck.

Tips

How to travel safely

Going on vacation? We’ve compiled a traveler’s guide to help you have an enjoyable safe time and completely get away from the routine.

Sign up to receive our headlines in your inbox
  • For all other countries