Tag Archives: security

Path traversal bugs in archive formats

Posted on February 28, 2019 | Comments Off on Path traversal bugs in archive formats

Malware has shown up which takes advantage of a path traversal bug in the WinRAR archiving utility. The bug, which reportedly existed for 19 years, is fixed in the latest version. The problem stems from an old, buggy DLL which WinRAR used. It allowed the expansion of an archive with a file that would be extracted to an absolute path rather than the destination folder. In this case, the path was the system startup folder. The next time the computer was rebooted, it would run the malware file.
Continue reading →

Comments Off on Path traversal bugs in archive formats

Posted in commentary, News

Tagged , ,

The “Zip Slip” vulnerability

Posted on June 14, 2018 | Comments Off on The “Zip Slip” vulnerability

Sometimes my reaction to a story is “Wait, are they saying someone was that dumb? … No one could be that dumb! … Oh, gods, they were that dumb!” Naked Security’s account of the Zip Slip vulnerability is just such a story.

The article starts with a fair warning that the vulnerability is “so simple you’ll need to put a cushion on your desk before you read any further (in case of involuntary headdesk injury).” It explains that because of the coding mistake called “Zip Slip,” “attackers can create Zip archives that use path traversal to overwrite important files on affected systems, either destroying them or replacing them with malicious alternatives.” This is where I started to suspect.

The vulnerability isn’t in the Zip format as such, but in bad coding found in some of the zillion ad hoc pieces of software written to unpack Zip files. Have you figured it out yet? I’ll put the cut here to give you a chance to think…
Continue reading →

Comments Off on The “Zip Slip” vulnerability

Posted in commentary, News

Tagged ,

Can a .txt file contain malware?

Posted on February 5, 2018 | Comments Off on Can a .txt file contain malware?

The Internet Crime Complaint Center reported that some email messages are impersonating it in an attempt to get malware onto target computers. That’s clearly worth knowing about, but this part of the report is odd:

The unknown actors also attached a text document (.txt) to download, complete, and return to the perpetrators. The text file contained malware which was designed to further victimize the recipient.

It really shouldn’t be possible to run malware by opening a .txt file. It should just open in a text editor, with no execution of code. There’s no further explanation.
Continue reading →

Comments Off on Can a .txt file contain malware?

Posted in commentary

Tagged

More on SVG risks

Posted on December 2, 2016 | Comments Off on More on SVG risks

SVG is a risky format in more ways than I’d realized. I’d previously mentioned the risk of cross-site scripting with embedded JavaScript, but I’ve found it gets worse.

The article “Crouching Tiger – Hidden Payload: Security Risks of Scalable Vector Graphics” covers the hazards in detail. There are two problems: (1) HTML5 requires SVG support in multiple contexts, and (2) SVG can have embedded JavaScript and CSS.

SVG is XML, and embedding it in HTML means switching between two different parsing modes. The author, Thorsten Holz at Ruhr-University Bochum, states that “SVG files must be considered fully functional, one-file web applications potentially containing HTML, JavaScript, Flash, and other interactive code structures.” I still haven’t digested all the content, but it describes lots of ways SVG could be exploited.

Websites that allow third-party posting should disallow or filter SVG content. WordPress disallows SVG uploads by default.

SVG is a designed-in danger in HTML5.

Comments Off on More on SVG risks

Posted in commentary

Tagged , ,

JavaScript risk in SVG images

Posted on November 21, 2016 | Comments Off on JavaScript risk in SVG images

Malicious SVG images sent over Facebook Messenger are being used to deliver Locky ransomware.

An SVG file can contain a <script> tag, which contains executable JavaScript as CDATA. If it’s an image on a Web page, the JavaScript can run in the browser. This is a potential XSS weakness, if users can submit images to a site.
Continue reading →

Comments Off on JavaScript risk in SVG images

Posted in commentary

Tagged , ,

Don’t hide those file extensions!

Posted on June 22, 2016 | Comments Off on Don’t hide those file extensions!

Lately I’ve ghostwritten several pieces on Internet security and how to protect yourself against malicious files. One point comes up over and over: Don’t hide file extensions! If you get a file called Evilware.pdf.exe, then Microsoft thinks you should see it as Evilware.pdf. The default setting on Windows conceals file extensions from you; you have to change a setting to view files by their actual names.

What’s this supposed to accomplish, besides making you think executable files are just documents? I keep seeing vague statements that this somehow “simplifies” things for users. If they see a file called “Document.pdf,” Microsoft’s marketing department thinks people will say, “What’s that .pdf at the end of the name? This is too bewildering and technical for me! I give up on this computer!”

They also seem to think that when people run a .exe file, not knowing it is one because the extension is hidden, and it turns out to be ransomware that encrypts all the files on the computer, that’s a reasonable price to pay for making file names look simpler. It’s always marketing departments that are to blame for this kind of stupidity; I’m sure the engineers know better.
Continue reading →

Comments Off on Don’t hide those file extensions!

Posted in commentary

Tagged , ,

Security risk in “target=_blank”

Posted on March 18, 2016 | Comments Off on Security risk in “target=_blank”

I’ve often used “target=_blank” in my posts so that people can click on a link without leaving the original page. So do many people. This turns out to be a seriously risky practice, though. When you open a window with an anchor tag specifying “target=_blank”, you give the target window control of the original window’s location object! This means that the target window can modify the content of the original window, possibly redirecting it to a phishing page.

We could also call this a security hole in the HTML DOM, or perhaps in the whole idea of allowing JavaScript in Web pages. I use NoScript with Firefox so that unfamiliar pages won’t run JavaScript, preventing them from exploiting this hole. I can’t expect everybody reading this blog to do that, though. To protect against exploits, I’d need to add “rel=noopener” for some browsers and “rel=”noreferrer” for others. That would require custom JavaScript, which wordpress.com won’t let me do, and would be a lot of work just to modify link behavior. Starting with this post, I’m not using “target=_blank” in my links. The sites I’ve linked to in the past are reputable, as far as I know, so the risk from existing links should be minimal. At least I hope so; supposedly trustworthy websites allow advertisers to include unvetted JavaScript, allowing malware attacks.

Comments Off on Security risk in “target=_blank”

Posted in News

Tagged ,

Unicode security mechanisms

Posted on January 14, 2016 | Comments Off on Unicode security mechanisms

Unicode is a great thing, but sometimes its thoroughness poses problems. Different character sets often include characters that look exactly like common ASCII characters in most fonts, and these can be used to spoof domain names. Sometimes this is called a homograph attack or script spoofing. For instance, someone might register the domain gοοgle.com, which looks a lot like “google.com,” but actually uses the Greek letter omicron instead of the Roman letter o. (Search this page in your browser for “google” if you don’t believe me.) Such tricks could lure unwary users into a phishing site. A real-life example, which didn’t even require more than ASCII, was a site called paypaI.com — that’s a capital I instead of a lower-case L, and they look the same in some fonts. That was way back in 2000.
Continue reading →

Comments Off on Unicode security mechanisms

Posted in commentary

Tagged ,

The misuses of HTML frames

Posted on November 21, 2014 | 1 comment

HTML framesets have some good uses, such as including third-party content. They also have misuses, such as disguising third-party involvement.

Recently I needed to set up domain forwarding for a subdomain registered with Godaddy. (The choice of registrar wasn’t my fault.) A couple of options were available, including one that claimed to guarantee that the subdomain would persist through navigation in the address bar. That sounded like a good thing, so I picked it.

At first it seemed to work fine; but when I tried to use the URL of an image on the site, there were weird errors. I soon found out what was going on: Godaddy was wrapping every page referenced by the subdomain in a frameset! This looks like a duck and clicks like a duck, but it isn’t one, and anything that tries to treat HTML as a JPEG file isn’t going to work very well.

Stack Overflow has several reports of people being bitten by this:

Frame wrapping is a good-enough solution for some cases, but when you aren’t told it’s happening, that’s a seriously wrong way to do it. It’s also a security concern, since your domain points at an IP address that you don’t control, and only indirectly at your own site.

This is a blog on file formats, not on irresponsible domain registrars, so the moral here is to realize that framesets aren’t a completely transparent way to provide third-party content. It’s fine to use them, but only if you’re aware that the frameset host and the frame provider are active partners.

1 Comment

Posted in commentary

Tagged ,

HTML5 security

Posted on February 25, 2011 | Comments Off on HTML5 security

Yesterday, February 24, Ming Chow gave a talk to the ABCD security group at Harvard on HTML5 security. As far as I can tell he hasn’t made any of the content publicly available online, but here are some high points:

  • HTML5 has a lot of new features, giving it a bigger “attack surface.”
  • There’s no effective security to local and session storage, so writing sensitive information there is a bad idea.
  • The database feature raises all the standard concerns about injection of malicious SQL code into fields.
  • Application caches can be written by any website. It may be possible to spoof pages this way.
  • There is now a function, XDomainRequest, in JavaScript, which allows communication between different sites. The receiver of the request must specify Access-Control-Allow-Origin to indicate whose requests are allowed. Wild-carding this allows anyone at all to send data to a page, which may be dangerous. Implementers of a receiver should always verify the sender’s identity.
  • With the audio, video, and canvas tags, the codecs can be vulnerable. Opera has been hit with a heap buffer overflow exploit in HTML5.
  • The noscript tag is no longer supported. Users who try to make themselves safer by disabling Javascript are more screwed than ever.
  • The problems are new, but the approach to safety is the same: common sense, input validation, being careful with unsecured connections, etc.

Comments Off on HTML5 security

Posted in News

Tagged , ,