Lots Of Recent Apple Security Patches

--

While I was taking a break to get over a cold, Apple has provided lots of new security patches. Here is my summary:

 I) Security Update 2013-001
(For Snow Leopard, Snow Leopard Server, Lion and Lion Server, included in OS X Mountain Lion Update 10.8.3)

Apple's security content document:

About the security content of OS X Mountain Lion v10.8.3 and Security Update 2013-001

Summary: Seventeen CVE issues were patched, covering twenty-one security issues in OS X.

CVE IDs:
(I have arranged the list chronologically and collected together the affected parts of OS X as a contrast to Apple's listing)

CVE-2011-3058 - Cross-site scripting attacks on EUC-JP encoded websites; Affecting international components for Unicode.

CVE-2012-2088 - Memory corruption caused by a maliciously crafted image; Affecting IOAcceleratorFamily.

CVE-2012-3488,
CVE-2012-3489 - SQL privileges escalation and other issues; Affecting PostgreSQL.

CVE-2012-3525 - Jabber dialback result messages rerouted by a remote attacker, disclosing information; Affecting the Jabber Messages Server.

CVE-2012-3749 - Bypassing of ASLR (address space layout randomization) and kernel address information disclosure; Affecting Kernel.

CVE-2012-3756 - Maliciously crafted MP4 files causing a buffer overflow; Affecting QuickTime.

CVE-2013-0156 - Ruby on Rails issue allowing remote attacker arbitrary code execution via XML parameters; Affecting Podcast Producer Server, Profile Manager, Ruby and Wiki Server.

CVE-2013-0333 - Ruby on Rails issue allowing remote attacker arbitrary code execution via JSON data; Affecting Podcast Producer Server and Wiki Server

CVE-2013-0963 - Bypass of certificate-based Apple ID authentication erroneously extending trust to a user; Affecting Identity Services.

CVE-2013-0966 - Attacker access to HTTP authentication protected directories via URIs containing ignorable Unicode character sequences; Affecting Apache.

CVE-2013-0967 - Maliciously crafted website Java Web Start application launching automatically despite the Java plug-in being disabled; Affects CoreTypes.

CVE-2013-0969 - VoiceOver allowed attacker with keyboard access to launch applications at the login window and modify the system configuration; Affecting Login Window.

CVE-2013-0970 - FaceTime:// URLs in Messages could be formatted to bypass the standard confirmation prompt and initiate a FaceTime call; Affecting Messages.

CVE-2013-0971 - Maliciously crafted PDFs could use ink annotations to cause memory management errors including unexpected application termination and arbitrary code execution; Affecting PDFKit.

CVE-2013-0973 - Plugins in Software Update's marketing text WebView could be used in a man-in-the-middle attack allowing arbitrary code execution; Affecting Software Update.

CVE-2013-0976 - Maliciously crafted images could cause unexpected system termination or arbitrary code execution; Affecting IOAcceleratorFamily.


II) OS X Mountain Lion Update 10.8.3
(Update and Combo Update)

Apple's security content document (same as above):

About the security content of OS X Mountain Lion v10.8.3 and Security Update 2013-001

The security patch content is the generally same as Security Update 2013-001 and Safari 6.0.3.

III) Safari v6.0.3
(Included as part of OS X 10.8.3 and Security Update 2013-001)

Apple's security content document:

About the security content of Safari 6.0.3

Summary: Seventeen security issues affecting WebKit.

CVE IDs: 

CVE-2012-2824,
CVE-2012-2857,
CVE-2013-0948,
CVE-2013-0949,
CVE-2013-0950,
CVE-2013-0951,
CVE-2013-0952,
CVE-2013-0953,
CVE-2013-0954,
CVE-2013-0955,
CVE-2013-0956,
CVE-2013-0958,
CVE-2013-0959,
CVE-2013-0960,
CVE-2013-0961 - A maliciously crafted website could cause unexpected application termination or arbitrary code execution, aka bad memory management.

CVE-2012-2889 - A maliciously crafted website could use frame elements to allow a cross-site scripting attack.

CVE-2013-0962 - Pasting content on a malicious website could allow a cross-site scripting attack.

IV) iOS 6.1.3

Apple's security content document:

About the security content of iOS 6.1.3

AHEM: Before I get into what this version of iOS fixes, I have to point out that iOS 6.1.3 allows yet-another passcode lock bypass. Sigh. This one enables anyone to use the phone for calls and provides access to the owner's photo gallery. That is all. But that is enough! Read about it and watch the break-in demonstration video at Sophos:

iOS 6.1.3 security flaw allows passcode lock bypass... again [VIDEO]

Summary: This update patched the screen lock bypass problem accessible via making an emergency call. The other five patches cover a variety of issues in WebKit, dyld, lockdownd, USB and the Kernel.

CVE-IDs:

CVE-2013-0912 - A maliciously crafted website could use SVG files to cause unexpected application termination or arbitrary code execution; Affects WebKit.

CVE-2013-0977 - Unsigned code could be executed could result from incorrect handling of Mach-O executable files with overlapping segments; Affects dyld.

CVE-2013-0978 - The addresses of structures in the kernel were disclosed via an issue in the ARM prefetch abort handler; Affects Kernel.

CVE-2013-0979 - Able to change permissions on arbitrary files that included a symbolic link after restoring from a backup; Affects LockDown / lockdownd.

CVE-2013-0980 - Screen lock bypass via a logic error in the handling of emergency calls form the lock screen; Affects Passcode Lock.

CVE-2013-0981 - Execution of arbitrary code via an issue with pipe object pointers in the IOUSBDeviceFamily driver; Affects USB.


V) Apple TV v5.2.1

Apple's security content document:
About the security content of Apple TV 5.2.1

Summary: The three patched security flaws are, not surprisingly, also found in iOS 6.1.3.

CVE-IDs:

CVE-2013-0977 - - Unsigned code could be executed could result from incorrect handling of Mach-O executable files with overlapping segments.

CVE-2013-0978 - The addresses of structures in the kernel were disclosed via an issue in the ARM prefetch abort handler.

CVE-2013-0981 - Execution of arbitrary code via an issue with pipe object pointers in the IOUSBDeviceFamily driver.


General Conclusion: As I often say, bad memory management is the bane of modern coding. However, it's interesting to see a wide variety of issues addressed in these updates, not just memory management. Hopefully, this indicates few memory management problems remain in Apple's software, causing attention to turn to other aspects of Apple code.

--

Adobe Critical Security Updates: Flash Player 11.6.602.180, AIR 3.6.0.6090. And: Looking Up CVE Numbers

--

Ping - Pong. 

Tick - Tock. 

Java - Flash. 

Oracle - Adobe. 

(0_o)

This week's Flash/AIR security update is out. Here is Adobe's announcement:

Security Bulletin: APSB13-09

Adobe has released security updates for Adobe Flash Player 11.6.602.171 and earlier versions for Windows and Macintosh, Adobe Flash Player 11.2.202.273 and earlier versions for Linux, Adobe Flash Player 11.1.115.47 and earlier versions for Android 4.x, and Adobe Flash Player 11.1.111.43 and earlier versions for Android 3.x and 2.x. These updates address vulnerabilities that could cause a crash and potentially allow an attacker to take control of the affected system.

Adobe recommends users update their product installations to the latest versions:

Users of Adobe Flash Player 11.6.602.171 and earlier versions for Windows and Macintosh should update to Adobe Flash Player 11.6.602.180.

. . .

Users of Adobe AIR 3.6.0.597 and earlier versions for Windows, Macintosh and Android should update to Adobe AIR 3.6.0.6090.

. . .

These updates resolve an integer overflow vulnerability that could lead to code execution (CVE-2013-0646).

These updates resolve a use-after-free vulnerability that could be exploited to execute arbitrary code (CVE-2013-0650).

These updates resolve a memory corruption vulnerability that could lead to code execution (CVE-2013-1371).

These updates resolve a heap buffer overflow vulnerability that could lead to code execution (CVE-2013-1375).

LOOKING UP CVE NUMBERS

If you'd like to know more about each CVE security hole, go to the Mitre.org CVE Search page, linked at the right, and enter each CVE code number (only) into the search box, and hit the Search button. (Leave off the 'CVE-' characters). Here is an example entry, along with the result:

If nothing about the CVE is yet listed at Mitre.org, try searching at SecurityTracker and SecurityFocus, also linked at the right. These two websites often have the dirt on a CVE security hole before it is approved for publication at Mitre.org. 

For Masochists Only: You can try searching for CVEs at the National Vulnerability Database (NVD) Search Vulnerabilities page, linked below. But I don't recommend it. Why? The site is a POS: Typical US government incompetent crap from hell. And I don't care what 'party' is in power. Major incompetent suckage is the rule. Example: At this very moment I cannot connect to the NVD website. My web browsers tell me: "Can't connect to the server "web.nvd.nist.gov". That's not acceptable. Also not acceptable is when the website is up and 'running' but the searches FAIL. Therefore, what is the point of the worthless NVD website? But if you just gotta try it:

http://web.nvd.nist.gov/view/vuln/search

... Told you so. This is how seriously the U.S. government takes computer security. :-P

--

AHA! Apple Institutes HTTPS (SSL) At iOS Store, At Long Bloody Last! But what about the BEAST Attack?!

--

An AHA! moment. 

So that's how user accounts at the iOS Store have been stolen! Apple has been foolishly using plain old in-the-clear http transactions at the iOS Store. How the $&%! was that allowed to happen? How incredibly incoherent and ignorant of Apple! Exceedingly Naughty!

After leaving users exposed, Apple fully HTTPS-protects iOS App Store (Updated)
But don't break out the bubbly yet. Apple engineers still have work to do.

Still have work to do?! WHAT?!!!!

It's great that Apple has finally updated its iOS app for App Store to provide this basic protection for the entire site. But the work isn't over yet. SSL Labs, a report card system from security firm Qualys that rates the quality of websites' HTTPS protections, gives Apple's App Store a failing grade. iOS users shouldn't worry too much, since the weaknesses Qualys is detecting aren't easy for the average hacker to exploit. Still, it shows Apple engineers still have work to do to make its customers safe.

QUALYS SSL LABS
SSL Report: itunes.apple.com (23.67.210.217)

Summary:

Overall Rating: F
Certificate Rating: 100
Protocol Support Rating: 0
Key Exchange: 40
Cipher Strength: 60
This server is vulnerable to the BEAST attack.

So, potentially for YEARS, essentially ALWAYS, Apple has had at least part of its iOS store transactions wide open, in-the-clear. This means that whenever someone using an iOS device connected to the Internet over an open WiFi connection, one without any encryption, one which didn't require you to log in or approve a license before you could connect, their IDs and passwords were sent through the air to the location's router for ANYONE to intercept and READ!!! You're literally handing over your Apple account identity to any local Hacker Rat. They've got the goods. You're hosed. They can do whatever they want with that information, including BEING YOU and FAKING that they are the iOS Store. Not good.

Remember the old Firesheep extension for Firefox? Ever heard of WireShark?

AND STILL PENDING:
Apple has not yet caught up with an over a year and a half old SSL/TLS exploit! The BEAST attack! I provided the link to a Qualys article on the BEAST attack above. Here is a simplified explanation at Wikipedia:

http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a "proof of concept" called BEAST ("Browser Exploit Against SSL/TLS") using a Java applet to violate same origin policy constraints, for a long-known Cipher block chaining (CBC) vulnerability in TLS 1.0. Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway[20] in 2002...

Mozilla updated the development versions of their NSS libraries to mitigate BEAST-like attacks. NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result.

. . .

As a work-around, the BEAST attack can also be prevented by removing all CBC ciphers from one's list of allowed ciphers—leaving only the RC4 cipher, which is still widely supported on most websites. Users of Windows 7 and Windows Server 2008 R2 can enable use of TLS 1.1 and 1.2, but this work-around will fail if it is not supported by the other end of the connection and will result in a fall-back to TLS 1.0.

For the serious geek, here is the original report on the BEAST attack (not average-user friendly!):

https://bugzilla.mozilla.org/show_bug.cgi?id=665814

Daniel Veditz [:dveditz] 2011-06-20 18:03:57 PDT

Thai Dong sent mail to security@ (and Apple, Microsoft, Google, Opera, CERT, and Oracle):

"This is Juliano Rizzo and Thai Duong. We are working on a new attack against SSL implementations on major web browsers and plugins. We are going to publish a preliminary result of our work next month. The published paper will include some browser exploits that can be used to decrypt HTTPS requests sent by browsers." . . .

Note the listed date in the quotation above: 2011-06-20, (June 20, 2011). The rest of the report continues as a comment thread through 2012-03-22, (March 22, 2o12). At that point the entire exploit was known to Apple and everyone else.

And Apple still hasn't finished fixing it.

FOR SHAME!

Bad show Apple. 
VERY bad show. 
Consider me (if I was a Japanese school girl), and many others, kicking you in the ass! 

GET MOVING APPLE!

--

4th Oracle Java Zero-Day, New Adobe Flash & Reader Zero-Days @ PWN2OWN CanSecWest 2013

--

Thank you to Sophos for keeping us up-to-date:

PWN2OWN results Day Two - Adobe Reader and Flash owned, Java felled yet again

Anyone surprised? If so, why? Comment below. ;-)

The Mantras:

1) Just Turn Java OFF. Only activate Java AFTER you have arrived at a trusted website, then reload the site. Be certain to Just Turn Java OFF Again, before you leave the trusted website. That is the only way to use Java and remain safe. Java is that dangerous, and Oracle doesn't give a rat's. We hate you Oracle!

2) Uninstall Adobe Reader and use anything else, such as Apple's provided Preview app. There is a plethora of alternatives, as listed in an earlier article.

3) Use a web browser click-to-Flash add-on/extension/plug-in, or just give up on this crap Adobe tech and uninstall it forever. There is a plethora of click-to-Flash add-ons, as listed in an earlier article. We hate you Adobe!

That's it for PWN2OWN 2013. What fun. (0_o)

See you soon with more Oracle & Adobe zero-day exploits, no doubt.
:-P

~~~~~~

BTW: I've added a list of friends and faves in computer security over on the right side of the blog page. Look under 'friends of Mac-Security'. I hope you find the list useful!

--

Three New Java Exploits @ PWN2OWN. Java 0day countdown webpage!

--

Wednesday, 2013-03-06.
Day One of the PWN2OWN contest at CanSecWest 2013. 
Java falls, three times. 
IE falls. 
Chrome for Windows falls. 
Firefox for Windows falls.

(Apple Safari wasn't tested at the contest. The best guess why is that no one had found a handy Safari exploit, probably a good thing).

So what are the THREE JAVA EXPLOITS? We're not going to know until they've been tossed over to Oracle and they've been patched.

~~~

How to keep track of the latest Java zero-day exploits:

Java 0Day countdown

This kewl, simple webpage provides a lot of useful information.

1) Check out the left side of the page to find out if your browser is SAFE from Java. If you effectively have Java OFF, as you should (!!!), you will see the following:

You're safe! Your browser Java support seems to be disabled.

navigator.javaEnabled() == false    

2) Also on the left, a search link for Java CVEs at the (decrepit) web.nvd.nist.gov website.

3) On the right are links to information about the most current Java zero-day exploits.

4) Also on the right, a link to find out 'Is it still a threat?' aka "is the patch useless yet?" *snark* You'll love the resulting page, very simple, very direct, in great big letters. Check it out now:

http://istherejava0day.com

Today the answer to that question is YES.

But guess what! It gets worse. According to one source, there may actually be more than 60 (SIXTY) known security holes in the current versions of Java. Even worse: Oracle has known about over 50 of those exploits for months, and done NOTHING to fix them. Instead of actually fixing their crapcode for all time, Oracle is patching their Java browser plug-in technology on a piecemeal basis. They're waiting for each security hole to become publicly exploited before they bother to patch it. And that sucks.

I'm going to be investigating this situation in a future article.

Conclusion: Expect Java security hell to continue for a long, long time.

Recite the mantra: JUST TURN JAVA OFF!

--

Java Updates! Apple: JRE 6u43 Oracle: Java Plug-in 7u17

--

DéDéDéjà vVvVu bZzzt@_@

Three Java patches are out, again!

I) From Apple: Java for Mac OS X 10.6 Update 14

This update includes:

- A) JRE (Java Runtime Engine) version 6u43 (1.6 update 43), installed into OS X. 

- B) Java Plug-in version 6u43

About Java for Mac OS X 10.6 Update 13
Java for Mac OS X 10.6 Update 13 delivers improved security, reliability, and compatibility by updating Java SE 6 to 1.6.0_41.

On systems that have not already installed Java for Mac OS X 10.6 update 9 or later, this update will configure web browsers to not automatically run Java applets. Java applets may be re-enabled by clicking the region labeled "Inactive plug-in" on a web page. If no applets have been run for an extended period of time, the Java web plug-in will deactivate.

Please quit any web browsers and Java applications before installing this update. 

About the security content of Java for OS X 2013-002 and Mac OS X v10.6 Update 14

Impact: Multiple vulnerabilities in Java 1.6.0_41

Description: Multiple vulnerabilities existed in Java 1.6.0_41, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues were addressed by updating to Java version 1.6.0_43. Further information is available via the Java website at
http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html 

CVE-ID

CVE-2013-0809

CVE-2013-1493

II) From Apple: Java for OS X 2013-002, for OS X 10.7 and 10.8.

About Java for OS X 2013-002

Java for OS X 2013-001 delivers improved security, reliability, and compatibility by updating Java SE 6 to 1.6.0_41.

On systems that have not already installed Java for OS X 2012-006, this update disables the Java SE 6 applet plug-in. To use applets on a web page, click on the region labeled "Missing plug-in" to download the latest version of the Java applet plug-in from Oracle.

Please quit any web browsers and Java applications before installing this update. 

About the security content of Java for OS X 2013-002 and Mac OS X v10.6 Update 14

Impact: Multiple vulnerabilities in Java 1.6.0_41

Description: Multiple vulnerabilities existed in Java 1.6.0_41, the most serious of which may allow an untrusted Java applet to execute arbitrary code outside the Java sandbox. Visiting a web page containing a maliciously crafted untrusted Java applet may lead to arbitrary code execution with the privileges of the current user. These issues were addressed by updating to Java version 1.6.0_43. Further information is available via the Java website at
http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html 

CVE-ID

CVE-2013-0809

CVE-2013-1493

As per usual, Apple's documentation is a MESS. The security page for Java for OS X 2013-002 is inexplicably labeled as being for 2013-001. (0_o) Hopefully, when you visit the page, someone at Apple will have noticed and repaired the blundering. Again, this is a long term problem with Apple's documentation team, incredibly confusing, annoying and dysfunctional. I'm calling them out, yet again. 

Dear Apple, please FIX YOUR DOCUMENTATION TEAM! For REALZ!

III) From Oracle: Java Plug-in 7u17, for OS X 10.7.3 - 10.8 only (not 10.6).

Java software for your computer, or the Java Runtime Environment, is also referred to as the Java Runtime, Runtime Environment, Runtime, JRE, Java Virtual Machine, Virtual Machine, Java VM, JVM, VM, or Java download.

Oracle Security Alert for CVE-2013-1493

Description

This Security Alert addresses security issues CVE-2013-1493 (US-CERT VU#688246) and another vulnerability affecting Java running in web browsers. These vulnerabilities are not applicable to Java running on servers, standalone Java desktop applications or embedded Java applications. They also do not affect Oracle server-based software.

These vulnerabilities may be remotely exploitable without authentication, i.e., they may be exploited over a network without the need for a username and password. For an exploit to be successful, an unsuspecting user running an affected release in a browser must visit a malicious web page that leverages these vulnerabilities. Successful exploits can impact the availability, integrity, and confidentiality of the user's system.

Due to the severity of these vulnerabilities, and the reported exploitation of CVE-2013-1493 "in the wild," Oracle strongly recommends that customers apply the updates provided by this Security Alert as soon as possible.

I've tested this update. The 'Control Panel' system preferences pane is the same cruddy thing as last time. The checkboxes do NOT work. Jam the 'Security' setting to 'Very High' and even then, don't count on it actually working properly. Instead, if you must use Java, keep Java OFF in all your web browsers until you are at a verified safe website, then turn Java on, then reload the website for functionality. Then, BEFORE you leave that web page, turn Java OFF again.

The concept is to avoid any possibility of drive-by Java infections from maliciously hacked web pages. We learned last month that an entirely reputable iOS development website was maliciously hacked such that many developers were drive-by infected via Java. This included certain individual computers at Apple, Twitter, Facebook and others being infected. IOW, it can be extremely difficult to know if a website is absolutely safe. The best option is to Just Turn Java OFF. Only turn it on when a website REQUIRES Java to run for a service you must use. Then be sure to Just Turn Java OFF again BEFORE you leave that website. This is critical. Java is that dangerous.

Summary:

For users of OS X 10.6, only, install Java for Mac OS X 10.6 Update 14.

For users of OS X 10.7.3 through 10.8.x, install BOTH Java for OS X 2013-002 and Oracle's Java Plug-in 7u17.

Be as safe as possible when surfing the Internet. Just Turn Java OFF until you require it. Just Turn Java OFF again immediately after you are finished using it.

Be seeing you, soon no doubt, for the next set of Java updates.

--

This Week's Reason To: JUST TURN JAVA OFF!

--

As one must expect, after the past many months of Java HELL, there is yet-another Java zero-day exploit out in-the-wild for the current versions of Java, both Java 6 and Java 7.

Therefore, recite our mantra and:

JUST TURN JAVA OFF!

I'm getting all emphatic about it, with caps and bold characters and added exclamation mark.

My advice: 
Give up on Java.
Uninstall Java.
Have a happier day.

Today's gory details:

New Java vulnerability is being exploited in the wild; disable the plugin or change your security settings

Better idea: 

Ignore Java's proven-to-be-worthless security settings and:

JUST TURN JAVA OFF!

YAJ0: YET ANOTHER JAVA ZERO-DAY

Through our Malware Protection Cloud (MPC), we detected a brand new Java zero-day vulnerability that was used to attack multiple customers. Specifically, we observed successful exploitation against browsers that have Java v1.6 Update 41 and Java v1.7 Update 15 installed.

Not like other popular Java vulnerabilities in which security manager can be disabled easily, this vulnerability leads to arbitrary memory read and write in JVM process. After triggering the vulnerability, exploit is looking for the memory which holds JVM internal data structure like if security manager is enabled or not, and then overwrites the chunk of memory as zero. Upon successful exploitation, it will download a McRAT executable (MD5: b6c8ede9e2153f2a1e650dfa05b59b99 as svchost.jpg) from same server hosting the JAR file and then execute it.

The exploit is not very reliable, as it tries to overwrite a big chunk of memory. As a result, in most cases, upon exploitation, we can still see the payload downloading, but it fails to execute and yields a JVM crash. When the McRAT successfully installs in the compromised endpoint as an EXE (MD5: 4d519bf53a8217adc4c15d15f0815993), it generates the following HTTP command and control traffic:

. . .

Update: Oracle assigned CVE-2013-1493 on this vulnerability.

And now, we get to do the sit-and-wait-for-Oracle-to-catch-up so they can spew out another lame update with further security holes yet-to-be-discovered. IASSOTS, etc. :-P

--