Tom Ferris Spots Mac OS X Bugs

By admin | Apr 23, 2006

Mac OS X.jpgMac fanatics usually chant the mantra of how rock solid Mac OS’s are. Being built of a *nix platform does inherently bring advantages. But anything in this world has vulnerabilities and Mac certainly is from this world. Tom Ferris, from the Security Protocols blog, has announced a number of buggy things with Mac OS X and Safari. Here is a list from Ferris’ blog on the various flaws:

  • Apple OS X 10.4.5 .tiff “LZWDecodeVector ()” Heap Overflow
  • Apple OS X BOM ArchiveHelper .zip Heap Overflow
  • Apple OS X Safari 2.0.3 Multiple Vulnerabilities
  • Apple OS X 10.4.6 “ReadBMP ()” .bmp Heap Overflow
  • Apple OS X 10.4.6 “CFAllocatorAllocate ()” .gif Heap Overflow
  • Apple OS X 10.4.6 .tiff “_cg_TIFFSetField ()” DoS
  • Apple OS X 10.4.6 .tiff “PredictorVSetField ()” Heap Overflow

Apple OS X 10.4.5 .tiff “LZWDecodeVector ()” Heap Overflow

Release Date:
April 3rd, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.5 and prior

Overview:
TIFF is a file format used mainly for storing images, including photographs and line art. Every TIFF file begins with a 2-byte field that indicates byte ordering: “II” for little endian and “MM” for big endian. The following two bytes contain the constant value 42. These values are followed by additional header fields and image data.

Technical Details:
When processing a malformed .tiff image file, the LZWDecodeVector() function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.

Below the crash is triggered on OS X (PPC) 10.4.5 using Safari within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0×32783fff
0×91be05a4 in LZWDecodeVector ()
(gdb) bt
#0 0×91be05a4 in LZWDecodeVector ()
#1 0×91bdf7d0 in _cg_TIFFReadEncodedStrip ()
#2 0×919904d4 in getBandProcTIFF ()
#3 0×9197b87c in CGImagePlusUpdateCache ()
#4 0×9197b590 in CGImagePlusCreateImage ()
#5 0×956a59bc in -[WebImageData _cacheImages:allImages:] ()
#6 0×956a5908 in -[WebImageData imageAtIndex:] ()
#7 0×956a6034 in -[WebImageData
drawImageAtIndex:inRect:fromRect:adjustedSize: compositeOperation:context:] ()
#8 0×956a5f18 in -[WebImageData drawImageAtIndex:inRect:fromRect: compositeOperation:context:] ()
#9 0×956a5e64 in -[WebImageRenderer drawImageInRect:fromRect: compositeOperator:context:] ()
#10 0×959307d8 in QPainter::drawFloatPixmap ()
#11 0×959305dc in QPainter::drawPixmap ()
#12 0×959304e8 in QPainter::drawPixmap ()
#13 0×95930490 in QPainter::drawPixmap ()
#14 0×959301f4 in khtml::RenderImage::paint ()
#15 0×95931520 in khtml::InlineBox::paint ()
#16 0×95930c08 in khtml::InlineFlowBox::paint ()
#17 0×959309b8 in khtml::RootInlineBox::paint ()
#18 0×9592f5f8 in khtml::RenderFlow::paintLines ()
#19 0×9592c538 in khtml::RenderBlock::paintObject ()
#20 0×9592c440 in khtml::RenderBlock::paint ()
#21 0×9592de4c in khtml::RenderBlock::paintChildren ()
#22 0×9592c548 in khtml::RenderBlock::paintObject ()
#23 0×9592c440 in khtml::RenderBlock::paint ()
#24 0×9592ae10 in khtml::RenderLayer::paintLayer ()
#25 0×9592aee0 in khtml::RenderLayer::paintLayer ()
#26 0×9592aa30 in KWQKHTMLPart::paint ()
#27 0×9592a968 in -[WebCoreBridge drawRect:withPainter:] ()
#28 0×9592a6f8 in -[WebCoreBridge drawRect:] ()
#29 0×956a5298 in -[WebHTMLView drawRect:] ()
#30 0×936c0e78 in -[NSView _drawRect:clip:] ()
#31 0×936c0438 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#32 0×956a220c in -[WebHTMLView(WebPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#33 0×936c3180 in _recursiveDisplayInRect2 ()
#34 0×9076d960 in CFArrayApplyFunction ()
#35 0×936c054c in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#36 0×936c3180 in _recursiveDisplayInRect2 ()
#37 0×9076d960 in CFArrayApplyFunction ()
#38 0×936c054c in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#39 0×936bfa00 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#40 0×936bffc8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#41 0×936bffc8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#42 0×936bffc8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#43 0×936bffc8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#44 0×936bffc8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#45 0×936e0664 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect: rectIsVisibleRectForView:topView:] ()
#46 0×936b9674 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#47 0×936ae968 in -[NSView displayIfNeeded] ()
#48 0×936ae7d8 in -[NSWindow displayIfNeeded] ()
#49 0×0001acb0 in ?? ()
#50 0×936ae684 in _handleWindowNeedsDisplay ()
#51 0×9075dcd8 in __CFRunLoopDoObservers ()
#52 0×9075df78 in __CFRunLoopRun ()
#53 0×9075da18 in CFRunLoopRunSpecific ()
#54 0×9317d1e0 in RunCurrentEventLoopInMode ()
#55 0×9317c7ec in ReceiveNextEventCommon ()
#56 0×9317c6e0 in BlockUntilNextEventMatchingListInMode ()
#57 0×9367b104 in _DPSNextEvent ()
#58 0×9367adc8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#59 0×00006e74 in ?? ()
#60 0×9367730c in -[NSApplication run] ()
#61 0×93767e68 in NSApplicationMain ()
#62 0×0005cbf0 in ?? ()
#63 0×0005ca94 in ?? ()
(gdb)

Solution:
This issue was silently fixed by Apple in update 10.4.6.
http://docs.info.apple.com/article.html?artnum=303411

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

————————————————————————-

Apple OS X BOM ArchiveHelper .zip Heap Overflow

Release Date:
April 19th, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior
BomArchiveHelper 10.4 (6.3) Build 312

Overview:
BOMArchiveHelper is the default archive file handler in Mac OS X. It runs as a service that does not have a GUI interface. It is invoked when double clicking on a archived file. A heap overflow vulnerability exists within BOMArchiveHelper which allows for an attacker to cause the application to crash, and or to execute arbitrary code on a targeted host.

Technical Details:
When decompressing specially crafted .zip file, the BOMStackPop () function incorrectly parses the malformed data and causes the application to segmentation fault.

Below the crash is triggered on OS X (PPC) 10.4.6 within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0×756e8897
[Switching to process 411 thread 0×3a03]
0×94498c14 in BOMStackPop ()
(gdb) bt
#0 0×94498c14 in BOMStackPop ()
#1 0×944994e4 in _copyDir ()
#2 0×944ab8fc in _copyFromPKZip ()
#3 0×94499060 in _copyDir ()
#4 0×944ab8fc in _copyFromPKZip ()
#5 0×944aa1ac in _BOMCopierCopyFromPKZip ()
#6 0×9449f270 in BOMCopierCopyWithOptions ()
#7 0×0000c8cc in ?? ()
#8 0×0000c1a0 in ?? ()
#9 0×00007360 in ?? ()
#10 0×00005938 in ?? ()
#11 0×928d46d4 in forkThreadForFunction ()
#12 0×9002b200 in _pthread_body ()
(gdb) disas BOMStackPop
Dump of assembler code for function BOMStackPop:
0×94498c08 : mr. r3,r3
0×94498c0c : li r11,0 0×94498c10 : beq- 0×94498c3c
0×94498c14 : lwz r2,8(r3)
0×94498c18 : cmpwi cr7,r2,0
0×94498c1c : ble- cr7,0×94498c3c
0×94498c20 : addi r2,r2,-1
0×94498c24 : lwz r9,0(r3)
0×94498c28 : li r0,0
0×94498c2c : stw r2,8(r3)
0×94498c30 : rlwinm r2,r2,2,0,29
0×94498c34 : lwzx r11,r2,r9
0×94498c38 : stwx r0,r2,r9
0×94498c3c : mr r3,r11
0×94498c40 : blr
End of assembler dump.

Solution:
This vulnerability was to Apple on 2/21/2006. No patch is available at this time.

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

———————————————————————–

Apple OS X Safari 2.0.3 Multiple Vulnerabilities

Release Date:
April 19th, 2006

Severity:
High

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior
Safari 2.0.3 (417.9.2) and all prior versions

Overview:
Multiple vulnerabilities exist within Safari 2.0.3 (417.9.2) and all prior versions which causes the application to crash, and or may allow for an attacker to execute arbitrary code. Below are the crash address, and links to basic PoC to reproduce the crashes.

Technical Details:
0×95940f9c in KWQListIteratorImpl::KWQListIteratorImpl () - sp-x26-1.html

0×95aa1b64 in QPainter::drawText () - sp-x26-2.html

0xfffeff20 in objc_msgSend_rtp () - sp-x26-4.html

Vendor Status:
Apple was notified of these issues on 01/06/2006.

Solution:
Currently no patches have been released for these vulnerabilities.

As Ilja has once said, “it is trivial to get Safari to crash”. He is right…

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

————————————————————————-

Apple OS X 10.4.6 “ReadBMP ()” .bmp Heap Overflow

Release Date:
April 19th, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior

Overview:
A heap overflow vulnerability exists when processing .bmp files which causes the application to crash, and or may allow for an attacker to execute arbitrary code on the targted host.

Technical Details:
When decompressing a specially crafted .bmp file, the ReadBMP () function incorrectly parses the malformed data and causes the application to segmentation fault.

Below the crash is triggered on OS X (PPC) 10.4.6 using Preview within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0×00000000
(gdb) bt
#0 0xffff8a60 in ___memcpy ()
#1 0×8f11c0d4 in ReadBMP ()
#2 0×8f11d528 in BMP_CDBandDecompress ()
#3 0×90b5bafc in CallComponentFunctionCommon ()
#4 0×90b5b684 in CallComponent ()
#5 0×8fad5680 in ImageCodecBandDecompress ()
#6 0×8fac70b8 in DoBandedDecompress ()
#7 0×8fb3fb98 in ICMAction_aligned ()
#8 0×8fac38e0 in ICMDeviceLoop ()
#9 0×8fac9dfc in DecompressSequenceFrameWhen ()
#10 0×8fafb224 in DecompressSequenceFrameS ()
#11 0×8f097b2c in importGraphicDrawInternal ()
#12 0×8f0992d0 in importGraphicDrawOrDecide ()
#13 0×90b5bae0 in CallComponentFunctionCommon ()
#14 0×90b5b684 in CallComponent ()
#15 0×90b5b684 in CallComponent ()
#16 0×8fafb05c in GraphicsImportDraw ()
#17 0×919948f8 in getBandProcQT ()
#18 0×9197b87c in CGImagePlusUpdateCache ()
#19 0×9197b590 in CGImagePlusCreateImage ()

Vendor Status:
Apple was notified.

Solution:
Currently no patches have been released for this vulnerability.

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

———————————————————————–

Apple OS X 10.4.6 “CFAllocatorAllocate ()” .gif Heap Overflow

Release Date:
April 19th, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior

Overview:
A heap overflow vulnerability exists when processing .gif files which causes the application to crash, and or may allow for an attacker to execute arbitrary code on the targted host.

Technical Details:
When decompressing a specially crafted .gif file, the CFAllocatorAllocate () function incorrectly parses the malformed data and causes the application to segmentation fault.

Below the crash is triggered on OS X (PPC) 10.4.6 using Safari within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0×19191921
[Switching to process 529 thread 0×6a8f]
0×90004688 in szone_malloc ()
(gdb) bt
#0 0×90004688 in szone_malloc ()
#1 0×0180016c in ?? ()
#2 0×907c2aa8 in CFAllocatorAllocate ()
#3 0×907c289c in _CFRuntimeCreateInstance ()
#4 0×903c4288 in createCache ()
#5 0×903c2e90 in initialize ()
#6 0×903c2b80 in create ()
#7 0×9043f120 in CGColorTransformCreateMutable ()
#8 0×9043f0b0 in CGBitmapColorTransformCreate ()
#9 0×9043efc0 in createBitmapContext ()
#10 0×9043e99c in CGBitmapContextCreateWithDictionary ()
#11 0×91a03540 in CGImageCreateCopyWithParameters ()
#12 0×919fffd0 in CGImageSourceCreateThumbnailAtIndex ()
#13 0×0000aac4 in ?? ()
#14 0×0000a858 in ?? ()
#15 0×000037d0 in ?? ()
#16 0×92977194 in forkThreadForFunction ()
#17 0×9002ba68 in _pthread_body ()
(gdb)

Vendor Status:
Apple was notified.

Solution:
Currently no patches have been released for this vulnerability.

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

————————————————————————–

Apple OS X 10.4.6 .tiff “_cg_TIFFSetField ()” DoS

Release Date:
April 19th, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior

Overview:
TIFF is a file format used mainly for storing images, including photographs and line art. Every TIFF file begins with a 2-byte field that indicates byte ordering: “II” for little endian and “MM” for big endian. The following two bytes contain the constant value 42. These values are followed by additional header fields and image data.

Technical Details:
When processing a malformed .tiff image file, the _cg_TIFFSetField () function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.

Below the crash is triggered on OS X (PPC) 10.4.6 using Safari within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0×00000000
0×00000000 in ?? ()
(gdb) bt
#0 0×00000000 in ?? ()
Cannot access memory at address 0×0
Cannot access memory at address 0×0
Cannot access memory at address 0×0
#1 0×91c71da4 in _cg_TIFFSetField ()
Cannot access memory at address 0×0
#2 0×91c73390 in TIFFFetchNormalTag ()
#3 0×91c7104c in TIFFReadDirectory ()
#4 0×91c706b0 in _cg_TIFFClientOpen ()
#5 0×919f2db8 in _CGImagePluginImageCountTIFF ()
#6 0×919f2c0c in CGImageSourceGetCount ()
#7 0×00004a84 in ?? ()
#8 0×93a52b68 in -[NSDocument _initWithContentsOfURL:ofType:error:] ()
#9 0×938dc360 in -[NSDocument initWithContentsOfURL:ofType:error:] ()
#10 0×00003f50 in ?? ()
#11 0×92984a00 in __NSFireMainThreadPerform ()
#12 0×90814f2c in __CFRunLoopPerformPerform ()
#13 0×907e4a68 in __CFRunLoopDoSources0 ()
#14 0×907e3f98 in __CFRunLoopRun ()
#15 0×907e3a18 in CFRunLoopRunSpecific ()
#16 0×9321e980 in RunCurrentEventLoopInMode ()
#17 0×9321df8c in ReceiveNextEventCommon ()
#18 0×9321de80 in BlockUntilNextEventMatchingListInMode ()
#19 0×93721104 in _DPSNextEvent ()
#20 0×93720dc8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#21 0×9371d30c in -[NSApplication run] ()
#22 0×9380de68 in NSApplicationMain ()
#23 0×00030fa4 in ?? ()
#24 0×00030e48 in ?? ()

Vendor Status:
Apple was notified.

Solution:
Currently no patches have been released for this vulnerability.

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

————————————————————————–

Apple OS X 10.4.6 .tiff “PredictorVSetField ()” Heap Overflow

Release Date:
April 19th, 2006

Severity:
Medium

Vendor:
Apple

Versions Affected:
Apple OS X 10.4.6 and prior

Overview:
TIFF is a file format used mainly for storing images, including photographs and line art. Every TIFF file begins with a 2-byte field that indicates byte ordering: “II” for little endian and “MM” for big endian. The following two bytes contain the constant value 42. These values are followed by additional header fields and image data.

Technical Details:
When processing a malformed .tiff image file, the PredictorVSetField () function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.

Below the crash is triggered on OS X (PPC) 10.4.6 using Preview within gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0×00000020
0×91c738f8 in PredictorVSetField ()
(gdb) bt
#0 0×91c738f8 in PredictorVSetField ()
#1 0×91c71da4 in _cg_TIFFSetField ()
#2 0×91c734b4 in TIFFFetchNormalTag ()
#3 0×91c7104c in TIFFReadDirectory ()
#4 0×91c706b0 in _cg_TIFFClientOpen ()
#5 0×919f2db8 in _CGImagePluginImageCountTIFF ()
#6 0×919f2c0c in CGImageSourceGetCount ()
#7 0×00004a84 in ?? ()
#8 0×93a52b68 in -[NSDocument _initWithContentsOfURL:ofType:error:] ()
#9 0×938dc360 in -[NSDocument initWithContentsOfURL:ofType:error:] ()
#10 0×00003f50 in ?? ()
#11 0×92984a00 in __NSFireMainThreadPerform ()
#12 0×90814f2c in __CFRunLoopPerformPerform ()
#13 0×907e4a68 in __CFRunLoopDoSources0 ()
#14 0×907e3f98 in __CFRunLoopRun ()
#15 0×907e3a18 in CFRunLoopRunSpecific ()
#16 0×9321e980 in RunCurrentEventLoopInMode ()
#17 0×9321df8c in ReceiveNextEventCommon ()
#18 0×9321de80 in BlockUntilNextEventMatchingListInMode ()
#19 0×93721104 in _DPSNextEvent ()
#20 0×93720dc8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#21 0×9371d30c in -[NSApplication run] ()
#22 0×9380de68 in NSApplicationMain ()
#23 0×00030fa4 in ?? ()
#24 0×00030e48 in ?? ()
(gdb) disas 0×91c738f8
Dump of assembler code for function PredictorVSetField:
0×91c738e8 : cmpwi cr7,r4,317
0×91c738ec : mr r9,r3
0×91c738f0 : lwz r11,444(r3)
0×91c738f4 : beq- cr7,0×91c73904
0×91c738f8 : lwz r12,32(r11)
0×91c738fc : mtctr r12
0×91c73900 : bctr
0×91c73904 : lhz r0,2(r5)
0×91c73908 : li r3,1
0×91c7390c : stw r0,0(r11)
0×91c73910 : lwz r2,40(r9)
0×91c73914 : lwz r0,12(r9)
0×91c73918 : ori r2,r2,4
0×91c7391c : ori r0,r0,8
0×91c73920 : stw r2,40(r9)
0×91c73924 : stw r0,12(r9)
0×91c73928 : blr
End of assembler dump.
(gdb)

Vendor Status:
Apple was notified.

Solution:
Currently no patches have been released for this vulnerability.

Discovered by:
Tom Ferris
tommy[at]security-protocols[dot]com

(Source: Tom Ferris at http://www.security-protocols.com)

[tags]Mac OS X flaws, Tom Ferris, Mac OS X Overflows[/tags]



Related Posts:

AOL Instant Messenger Security Issue
Okay, you're chatting with your friends on AIM (AOL Instant Messenger) and suddenly you've been exploited. Somehow, someone has...

Microbial Alternative Fuel Cells
With the need for renewable, cheap, and environmentally friendly fuel increasing, researchers are turning to alternative fuel methods with renewed...

VIOLight Toothbrush Sanitizer
Your mouth has tons of bacteria in it. I've heard it said that a human bite is cause for...

“Storm” Warning: Worms Getting More Vicious
The Storm Trojan. One of the nastiest viruses to hit the 'Net in some time has really been active as...

Is a Voting Machine a Good Thing?
Technology is a two edged sword. Technology can grant enormous power to the wielder. But dependence on technology,...
3 Comments so far
  1. Ryan Vo April 23, 2006 9:24 pm

    Of course there will be security holes (it’s a fairly large chunk of code), but the vulnerabilities are acted upon less because of the smaller OSX audience. Either way, Windows is still far more vulnerable than OSX.

  2. kevin ashton April 24, 2006 9:05 am

    Never The Less…………

    Having used both windows Pc’s and Mac os computers along time…I can say with out doubt two things…

    One. I can complete my work on a mac faster..always, regardless of the type of work.

    Two. you would not be trying to hilight the failures of the Mac OS if you had ever spent any great amount of time using one. Then you would undestand why macusers are so enthusiastic about Mac computers.

  3. Administrator April 24, 2006 9:39 am

    Kevin, actually I have spent a lot of time on Mac. That doesn’t preclude me from pointing out known flaws, just like it wouldn’t preclude me from pointing out flaws on linux or windows. i’m not doubting reasons for mac users’ enthusiasm.

Leave a Comment

If you would like to make a comment, please fill out the form below.

Name (required)

Email (required)

Website

Comments

© 2007 PaulTech Network, - Daily Blog Tips Themes