Feeds

back to article Microsoft in a TIFF over Windows, Office bug that runs code hidden in pics

Microsoft has alerted users and system administrators following the discovery of targeted attacks on a security bug present in Windows, Office and Lync. The software giant said the flaw allows attackers to remotely execute code and install malware on a vulnerable system by sending an email or instant message or convincing a user …

COMMENTS

This topic is closed for new posts.
Silver badge

How? Why?

Under what obscure circumstance would someone write code to process an image that allows it to treat the image as executable code? Is this some wierd NSA backdoor that they're owning up to?

8
3
(Written by Reg staff) Silver badge

Re: How? Why?

It'll be more complex than that. A specially crafted TIFF file will trigger a bug that causes the malicious code to be copied into memory. Then a series of techniques are pulled off to guide the processor into executing that code in memory - see the MS blog post for a bit more info on this.

C.

2
0
Anonymous Coward

Re: How? Why?

http://insecure.org/stf/smashstack.html

2
0
Anonymous Coward

Re: How? Why?

@Dio - The tin foil hat prevents radio signals and facts from going into the brain so the best way to answer this type of question is with his truth...

Yes it is a backdoor. Since the tin foil hat you're wearing is blocking their radio signals, the NSA planted a backdoor in MS to program you via tiff's on orders from our kitten overlords.

4
1
Bronze badge

Re: How? Why? Stack handling

It does seem that a common theme to many of the vulnerabilities we've seen on Windows over the years have been around malformed file formats and stack handling. So it would seem that this whole area is a weakness. Whether it is just Windows not using the protection features of the Intel chips correctly or not, I don't know, but I do question whether Linux and other OS's really have got stack security totally sewn up.

Interestingly, one of the things I've often included in enterprise solutions since circa 2005 has been an XML firewall, so that all inbound B2B XML traffic is validated externally to the application server - this came about in part from initial experiences of using BizTalk Server in a solution...

As an aside another 'fun' thing with C, is that different libraries handle the moving of a file point beyond the end of a file differently.

0
1
Silver badge
Mushroom

Re: How? Why? Stack handling

F*CKING RETARDS!

1) 1992 or thereabouts - Someone made a joke about the .jpg of death on Usenet, as a totally fanciful concept.

2) 2004 or thereabouts - .jpg of death actually surfaces via - wait for it - Internet Explorer

3) ???

4) 2013 - TIFF of death surfaces via - wait for it - Windows

It's so crap I can barely believe it. It's the utter crap of crapper's worst crap in the crappiest part of crapland.

Or a deniable backdoor.

YOU DECIDE!

4
2

Re: How? Why? Stack handling

http://en.wikipedia.org/wiki/Libtiff#Exploits

It's not unheard of in the Linux world either. Tiff isn't a jpg at all, much more complicated format used in the business and medical world pretty often.

3
0
Anonymous Coward

Re: How? Why? Stack handling

@Destroy All Monsters: rarely have I agreed with a comment more.

It's not like that the idea is *new* - an image causing something to be EXECUTED? In my opinion, that should happen to people who allow this sort of code out in the wild in the first place. I have yet to see *ANY*, and I mean *ANY* code emerge from Redmond since Worries for Workgroups that didn't show seriously shoddy coding practices in all sorts of places. It's so frequent it leaves no other conclusion that this is done deliberately.

Yet, this is the stuff that people keep showing me as "Enterprise ready" (usually when it's about using OSX instead) - oh really? This stuff is only Enterprise ready if you're looking for a mass install of a single point of failure. Sure, they'll fix this one, but that either means there's another 1000 waiting to be fixed, or the patch introduces another problem. And on and on it goes, the corpse kept alive by people who would otherwise no longer have a job.

The latter is about the only reason I don't kick MS too hard: there is a vast ecosystem around Microsoft that is in the business of selling sticky tape, bandages and crutches to keep it going, and to protect executives from the consequences of their own decisions. I cannot in good conscience make people lose their job. No, seriously.

3
0
Silver badge

Re: How? Why? Stack handling

Better than their wmf bug that let you run arbitrary windows commands by just putting "#command" in the file

0
0
Bronze badge

Re: How? Why? Stack handling

It does seem that a common theme to many of the vulnerabilities we've seen on Windows over the years have been around malformed file formats and stack handling. So it would seem that this whole area is a weakness. Whether it is just Windows not using the protection features of the Intel chips correctly or not, I don't know, but I do question whether Linux and other OS's really have got stack security totally sewn up.

Really, folks, you could all do a bit of reading before posting stuff like this. Though at least this is better than the various "why is there executable code in an image file format?!!" cries of outrage.

Yes, a great many exploits - and this is by no means confined to Windows - do involve stack-smashing (or similar attacks, such as heap-smashing) and processing (relatively) complex file formats. That should not come as a surprise to anyone who possesses even a glancing familiarity with the past couple decades of software vulnerabilities.

There are many stack-related vulnerabilities because popular languages, such as C, offer ample opportunity to create them, and popular implementations don't guard against them. (The latter has changed somewhat over the past decade or so with stack canaries and similar techniques, but it's an arms race.)

Exploiting a stack-related vulnerability involves getting the vulnerable software to process malicious input. Where might that input come from? Gosh, a file might be a good source! Particularly when said file involves a complex format that may have encouraged sloppy implementors to take shortcuts, such as sanity-checking embedded length values.

In a UNIX-style filesystem, where everything is treated as a byte stream, files are serialized representations of data - almost always data with some structure. That means they employ in-band signalling (like the aforementioned embedded length values). In-band signalling is a notorious source of error and security vulnerability.

0
0
Bronze badge

Re: How? Why? Stack handling

1) 1992 or thereabouts - Someone made a joke about the .jpg of death on Usenet, as a totally fanciful concept.

2) 2004 or thereabouts - .jpg of death actually surfaces via - wait for it - Internet Explorer

You're missing a few points of interest there.

- Around 2000, there was discussion of potential vulnerabilities in various image file formats, particularly ones that involved complex processing, such as Windows metafiles. The WMF format was particularly worrisome because Outlook would display metafiles attached to messages with no prompting and no way to disable that misbehavior.

- In February 2004, we had a public example of a malicious WMF/EMF that would freeze Windows Explorer, which may not be terribly exciting but is certainly proof-of-concept.

- The "JPEG of Death" you refer to was probably MS04-028, the vulnerability in the GDI+ JPEG decoder, disclosed in September 2004. An exploit appeared shortly thereafter.

- But well before that, we knew that all Netscape browsers since at least 3.0, and running up to 4.73, had vulnerable broken JPEG implementations; Solar Designer published on that in 2000. So the 2004 JPEG of Death was rather late to the party.

- Then, wouldn't ya know it, the next year we found out that essentially the same bug was in the IE JPEG decoder. Oops!

- Numerous developers independently recreated this problem, as users of the JPEG2000 plugin for Foxit Reader discovered in 2009. (Or maybe they didn't, if they weren't paying attention.) The same year also saw the same bug in various Java runtimes. And so on.

- Meanwhile, in 2008, we discovered that Microsoft could even screw up GIF and BMP processing in a vulnerable fashion.

- What about Apple? Sure, Quicktime was found to be vulnerable to malicious image files in a variety of formats in 2005. Including TIFF.

I could go on, but suffice it to say that:

1. Processing complex file formats, such as many image file formats, is tricky. And developers are lazy, and they get it wrong. Most of the time, and regardless of for whom they work.

2. There's nothing new here. We've seen this many, many times over the years. We'll continue to see it for the foreseeable future.

0
0
Bronze badge
Mushroom

Who the hell designs a PICTURE format with executable code in it????

5
5

Oooh I know the answer to this one, is it Microsoft?

A much more difficult question would be why?

5
1
Silver badge

In this case they didn't — it's a standard buffer overflow attack.

But if you're asking who would? Well, early-1990s Microsoft did in WMF. They closed that hole back in 2006 but you should be able to find ample reporting from then.

2
0
Silver badge
Pint

Put the pixels on the screen

Nothing else.

Stupid. Stupid. Stupid.

3
2
Silver badge
Headmaster

Re: Put the pixels on the screen

Look, I don't want to look like I'm going all Defender Of Microsoft here (I wouldn't want to ruin my reputation after all) but your simplistic comment demonstrates a certain ignorance of how these things work.

Specifically, a TIFF is not a bitmap, it is a compressed format. Before you can "put the pixels on the screen" you must first decompress it.

This is where your budding script kiddy has a chance to exploit any bugs in the decompression code (by providing a malformed TIFF file) and thereby initiate a buffer overrun or some other crash that causes a stack trace to occur.

Once you have done that you have your malware in memory and then all you need to do is find a way to execute it from there.

HTH

10
0
Bronze badge

Re: Put the pixels on the screen

"...then all you need to do is find a way to execute it from there."

That isn't exactly as easy as you make it sound. In fact, this is the real problem behind this exploit. Somehow Microsoft has allowed execution of code that doesn't have to have tight bounds checks and no validation of what it has just copied. With that kind of code, is pointer manipulation really a surprise? No, it's not only expected, it's in many ways the correct default behavior.

My take is that Microsoft is just assuming that the train will arrive on time, because it left on time. There is a whole lot of "What The Fuck?" in that considering this is billion dollar corporation.

3
1
Silver badge

Re: Put the pixels on the screen

I was merely attempting to point out that there is more going on here than simply "putting the pixels on the screen".

Apparently I was not successful in that respect.

3
0
Gold badge

Re: Put the pixels on the screen

I was merely attempting to point out that there is more going on here than simply "putting the pixels on the screen".

Apparently I was not successful in that respect.

I think you did OK, but it wasn't the question. The question was why this is STILL a problem. TIFF is not exactly a new format, and the whole handling framework of this format should have been stable many, many years ago. The absence of sanity in this respect (especially in the light of the vast amount of exploits that have taken place already) borders on criminal neglect IMHO.

2
0
Bronze badge

Re: Put the pixels on the screen

TIFF is not exactly a new format, and the whole handling framework of this format should have been stable many, many years ago. The absence of sanity in this respect (especially in the light of the vast amount of exploits that have taken place already) borders on criminal neglect IMHO.

If that's criminal, developers are going to be a mighty scarce breed soon.

See my post above. Many, many developers have made this sort of error, even just in this very narrow area (decoding image files). We've been seeing this particular exploit category - malformed image files lead to buffer overflow that can be leveraged to execute malicious code - for at least 15 years. In software from a variety of major organizations (Microsoft, Apple, Netscape, etc).

There's a reason why "Buffer Overruns" is #1 in 19 Deadly Sins of Software Security, and holds a similar place in similar lists. (And integer overflow is #3, beaten by format-string errors mostly because exploitable integer overflows were a bit rarer in 2005, when the book was published.) Buffer-overrun errors are easy to create. If you're using a language that doesn't enforce boundaries for you, they're a pain to police. So programmers don't bother.

0
0
Silver badge

No ...

You can cleverly craft broken formats to break the program* reading the data (simplest is String Buffer Over runs/ Array bound violations).

It's not necessary that the format is MEANT to have executable code in it.

But it must be six years since I opened MS software to view a TIFF from Internet (it a was a multipage Tiff, which oddly most photo editing SW/viewers can only see 1st page). Is the default Windows Image Preview/Printer application of XP and later Windows vulnerable?

(* or a 3rd party library the programmer of the program used)

0
0
Bronze badge

Typical code bug, bad checks on incoming data

This isn't about standard code being embedded in the TIFF file, it's about the TIFF file being subverted so that the programs reading it will suck in the bad code, and then execute TIFF data as though it were code.

Specifically, the exploit code performs a large memory heap-spray using ActiveX controls (instead of the usual scripting) and uses hardcoded ROP gadgets to allocate executable pages.

Check out the MS links in the article about how to get around the problem for now.

0
0
Anonymous Coward

Re: Typical code bug, bad checks on incoming data

Ah that answers the question, ActiveX being the Achilles heel yet again.

3
0
Bronze badge
Coat

Buffer overrun

Mr Rogers to Microsoft coders: "Can you say 'buffer overrun exploit' boys and girls? I knew you could."

Putting on trademark Cardigan sweater.

3
0
Bronze badge

Re: Buffer overrun

Given how many times they've heard it / done it in the past, clearly they can.

Perhaps the promise of decimation, proper Roman style, for the next team that allows one would concentrate their minds.

0
0
Bronze badge

Gees

I suggested 'hackers' have the ability to create patches for exploits like this (since Microsoft won't be for XP any more) and get down voted and a dumb arse telling me you can't patch code without source.

It is a damn sight easier patching an executable file with the users consent than it is to patch an exploit into an executable in memory by feeding it mal-formed data. Neither requires source code.

How many more similar clueless comments will we get here?

6
0
Anonymous Coward

"the attacker's code hidden in the image file executes on the target system with the same privileges as the current user."

So Windows 7 & 8 users should be fine then unless they disabled UAC....

0
2
Anonymous Coward

Windows 7 & 8 users should be fine?

"We believe that the attacks against DEP and ASLR cannot be completely avoided due to the vulnerabilities in operating systems or security-critical applications."

https://www1.comp.nus.edu.sg/~liangzk/papers/acsac10.pdf

2
0
Anonymous Coward

Re: Windows 7 & 8 users should be fine?

Sounds like you need to Bing UAC....

Windows 7 and Windows 8 users don't run with admin access by default...

0
3
Silver badge
Unhappy

Re: Windows 7 & 8 users should be fine?

" Windows 7 and Windows 8 users don't run with admin access by default..."

The problem with that is that a virus could still delete your personal files, and anything else you are able to do without admin..

Can a non-admin create startup scripts by default? (I ask. because I dont know)

The thing is, a lot can be done without admin privs - even a spamming-daemon (though it's ability to hide is restricted, and it's general effectiveness is greatly reduced if it can't configure auto-startup [see above])

1
0
Anonymous Coward

Re: Windows 7 & 8 users should be fine?

"Can a non-admin create startup scripts by default? (I ask. because I dont know)"

Not that would have any greater access than the user did already...

0
0
Silver badge

Re: Windows 7 & 8 users should be fine?

"The problem with that is that a virus could still delete your personal files"

Correctamundo!

Not to mention an infected user stands a good chance of having their Internet banking details, email lists and other personal data slurped up and sent off to some Armenian mafia group.

What, me worry?

It is ludicrous to approach computer security with a view that as long as the root is not compromised then everything is AOK but apparently there are plenty of people who should know better who do just that.

2
0
Silver badge

Re: Windows 7 & 8 users should be fine?

"Sounds like you need to Bing UAC...."

Surely you mean Google...

2
1

A good while back I remember seeing a beautifully simply quicktime exploit with MP3's

http://www.gnucitizen.org/blog/backdooring-mp3-files/

There used be a load of MP3 exploits due to the amount of dodgy mp3 players around...

Let's not forget MS04-28 - http://technet.microsoft.com/en-us/security/bulletin/ms04-028

Then of course we have all things Adobe...

Not a surprise anymore, but if things don't improve we'll be seeing just downright vicious attacks rendering swathes of machines and data dead in the water - all we need is a call to arms from one group vs something somebody did on another continent.

3
0
Anonymous Coward

At least it doesn't give you root access like this hole does:

http://arstechnica.com/security/2013/05/critical-linux-vulnerability-imperils-users-even-after-silent-fix/

0
10
Bronze badge

Way to derail the thread. There isn't even a touch of comedy to it, It's just blatant.

If people like Eadon get banned for derailing a thread into anti-Microsoft, then shouldn't people also get banned by derailing a thread into anti-Linux?

This user is posting as Anonymous Coward, so there is no we can tell if this user is commonly seen in fashionable troll attire.

7
1
Anonymous Coward

Let's not even go there shall we.

The security record of Windows is shocking.Early in the design process convenience over security was the selection and that failed architecture has been carried through to the present day. It's so bad the US military won't use it:

http://arstechnica.com/information-technology/2013/10/the-navys-newest-warship-is-powered-by-linux/

0
0
Anonymous Coward

Re: Let's not even go there shall we.

"It's so bad the US military won't use it:"

Actually the US military and the British Army and Navy overwhelmingly use Windows. Specifically because of historical security concerns around Linux. Google 'Windows for Warships'....

Linux has for years had an inferior security architecture to Windows (for instance drivers not isolated from the kernel, no constrained delegation, having to run an experimental file system to get proper ACLs, etc, etc.) - these issues have finally been bodged around with patches like SEL....meaning that Linux can now in some cases compete with Windows in these environments.....

0
4
Anonymous Coward

Re: Let's not even go there shall we. @Muppet 09:00

Fine, you use Windows for home banking and financial transactions, I'll stick with Linux. When you get whacked I'm sure Wonga and their eye watering interest rates will help you out until the mess is sorted.

http://www.theregister.co.uk/2012/01/12/drone_consoles_linux_switch/

2
0
Roo
Silver badge

Re: Let's not even go there shall we.

"Actually the US military and the British Army and Navy overwhelmingly use Windows."

Indeed, and now in some cases they have decided Windows is not fit for purpose any more because it got infected and hacked.

"Specifically because of historical security concerns around Linux."

What were those concerns ?

2
0
Anonymous Coward

Re: Let's not even go there shall we.

"What were those concerns ?"

Presumably the extremely high vulnerability counts in Linux distributions for a start. SUSE 10 is on over 3,800.... Plus the architectural shortcomings above compared to Windows...

0
5
Anonymous Coward

Re: Let's not even go there shall we. @Muppet 09:00

"http://www.theregister.co.uk/2012/01/12/drone_consoles_linux_switch/"

Yes - that's the main use for Linux - isolated command and control systems where the vulnerability risk from Linux is not too great. For networked systems they primarily use Windows...

0
4
Bronze badge

U.S. Navy's warship of the future runs Linux

@anonymous: "Actually the US military and the British Army and Navy overwhelmingly use Windows. Specifically because of historical security concerns around Linux. Google 'Windows for Warships'"

"U.S. Navy's warship of the future runs Linux"

http://www.dvice.com/2013-10-24/us-navys-warship-future-runs-linux

"Sunk by Windows NT"

http://www.wired.com/science/discoveries/news/1998/07/13987

0
0
Roo
Silver badge

Re: Let's not even go there shall we. @Muppet 09:00

"Yes - that's the main use for Linux - isolated command and control systems where the vulnerability risk from Linux is not too great. For networked systems they primarily use Windows..."

Right, so they can get hacked by amateurs in their bedroom like Gary McKinnon.

1
0
Roo
Silver badge

Re: Let's not even go there shall we.

"Presumably the extremely high vulnerability counts in Linux distributions for a start. SUSE 10 is on over 3,800.... Plus the architectural shortcomings above compared to Windows..."

"Presumably" you posted as AC because you are unwilling to stand by what you posted.

"Presumably" you think it is preferable that safety & security critical systems run an OS where the vendor has made it policy to publish vulnerabilities several months after they have been discovered and exploited. Microsoft et al also pay security researchers hush money as a matter of policy, they are going to extraordinary lengths to keep their vulnerabilities hidden so I would be very disappointed for them if that sheer weight of cash failed to keep the published vuln's lower than it should be.

With all else being equal, I would expect a higher *published* vulnerability count from an open source project that conducts it's development in public vs a vendor that conducts development in private, pays people to keep quiet about vulnerabilities and sues people into the ground who don't play ball. Conversely I expect the *actual* vulnerability count of the open source project to be much lower because the barriers to discovery and fixing the vulnerabilities are far lower than the vendor software.

Also there is another factor. Vendors have a habit of writing code with a view to getting them to market as quickly as possible. This leads to immature code being released - and that in turn leads to more bugs and more vulnerabilities. "Presumably" you think Windows developers buck this trend somehow, despite the abundant evidence to the contrary.

0
0

Actually he got tossed for calling people shills one to many times.

1
0
Thumb Up

Oooh, if it's that easy, there is a girl in accounts I am gonna call a shill later on....

0
0

Healthcare.gov

That is what is wrong with the bleeping computers running the socialist "market" for insurance in the US. Microsoft software and images that are TIFFs! Need to start all over, but try dental insurance first using JPGs to get the bugs out before moving to health coverage (a matter of life and death) and TIFFs. Some Asian cultures have lived just fine with crooked teeth.

0
0
This topic is closed for new posts.