Fresh Apple Patches

Published: 2006-03-02
Last Updated: 2006-03-02 18:27:17 UTC
by Swa Frantzen (Version: 2)
0 comment(s)

Apple released a security update called "2006-001".  It is claiming to update following components:

Also described in the release notes are:

For detailed information on this update, we'll refer you to apple's article 303382.

This update is very critical to install on your Mac OS X machines:

  • safari gets fixes for 4 separate issues: one of them with the public PoC; 3 of them result in arbitrary code execution and one looks like it allows javascript access to local resources.
    At this point it's unclear how effective the patch against the PoC is. To quote Apple: "This update addresses the issue by performing additional download validation so that the user is warned (in Mac OS X v10.4.5) or the download is not automatically opened (in Mac OS X v10.3.9)". We know from experience that warning users is hardly enough in real life. Still it's better than nothing.
  • ichat, mail get file type protection warnings in an effort to help twarth the worm threat (as exposed by the PoC virus Leap.A)
  • The Directory services vulnerability already has an exploit publicly available allowing local privilege escalation.
  • many more ... but you get those fixes for free anyway

On the not so good side: (before I get every Apple fan on my case: I love my powerbook, but it does not mean Apple should not clean up their act a bit)

  • Nice to get an update to PHP 4.4.1, but do note that a quick visit to php.net learns that it released PHP 4.4.1 on October 31st, 2005. That's 4 months!  Add to that that PHP 4.4.2 has been released on January 13th, 2006.  For a open source package this isn't cutting it I'm afraid. Apple really needs to speed up it's testing and dramatically reduce the window of exposure (even if it's not enabled by default).
  • Apple references article 108009 but it's putting all responsability with the end user. Can't we please have it promote using things like anti-virus and other malware preventing software? Sure users should not accept everything and click on anything. But the windows world has proven this approach doesn't work well enough once the OS gets targeted by malware.

UPDATED to include CVE numbers (many are still not public, but that will most likely change soon)

--
Swa Frantzen

Keywords:
0 comment(s)

A Bunch Of Bull in a China Shop

Published: 2006-03-02
Last Updated: 2006-03-02 16:55:36 UTC
by Tom Liston (Version: 1)
0 comment(s)
Over the past several days, we've been deluged with responses to our story on Professor Packetslinger and his assignment.  The number of lawyer-wannabes among the infosec community appears to be at an all-time high, and so I've decided to step into the fray and offer a little unsolicited, yet sage advice:

If you think being a geek drives away chicks, being a lawyer is, if anything, worse.

That being said, I'd also like to toss out one more tidbit of wisdom that I've accumulated over time, like mold, within this lump of goo situated between my ears:

The legality of port scanning is an unsettled matter.  The legality of breaking someone else's machine or causing monetary damage isn't.  The problem is this: there's no difference between the two when it happens... and then it's too late.

(Note: I'll tempt fate.  Honey... please don't leave me 'cause of this.. OK?) 

The case that the budding Perry Mason's keep tossing at us is Moulton v. VC3:
  1. This is a civil, not a criminal case.  For those of you who keep claiming that this case proves that port scanning is legal, here is a dime. Take it, call your mother, and tell her there is serious doubt about you ever becoming a lawyer. (...with apologies to Prof. Charles Kingsfield.)
  2. While there was a criminal investigation that preceeded the whole Moulton v VC3 (and VC3 v Moulton) hoopla, all it spoke to was that the costs of investigating a port scan could not be used to push the case beyond the damage limit for criminal prosecution.  The judge stated that the statute required "that the damage must be an impairment to the integrity and availability of the network", and that this particular case did not meet that criteria.
  3. Remember: Most computer crime cases are about damages, and damages are all about interpretation.  This particular damage interpretation took place in the year 2000.  The "cost" of a security incident is a very slippery subject.  Care to be a 2006 test case?
When I take my kids out shopping, and we wander through a store chock full o' purty yet breakable things, a strange compulsion comes over me and I pop out with the typical "Dad" mantra: "We look with our eyes, not with our hands... keep 'em in your pockets."  And while they're all getting to the age now where they just look at me and roll their eyes, the advice is still solid.  In my own way, I'm teaching them an important rule that all adults know, believe, and put into practice in their daily lives: Don't take unnecessary risks.  While it's fun to look at the pretty glass unicorns and that bone china vase is awfully nice... picking them up and playing around with them can only lead to problems.

Ask any infosec professional who has been around the block a time or three, and they'll be able to tell you stories about systems they've popped with nothing but a port scan.  I've been there, I've done that, and I've got the "I tipped over a system using Nmap" t-shirt to prove it.  Stepping beyond simple port scans to vulnerability scans is fraught with even more peril.

The point is this.  If you're learning to be a professional, you need to act like a professional.  If I fired off an on-site or remote test of a client without a signed "get out of jail free" document, my employer should, by rights, discharge me immediately.  While the liability is, perhaps, low and there might be a decent argument that exposing machines that can tip over at the drop of a hat on any network is negligence, it doesn't change the fact that I am acting unprofessionally in this circumstance.

Professionals get permission, in writing, in advance.  If you're not doing that, you're an attacker doing recon, despite how much you might want to convince yourself to the contrary.  And while your actions by themselves may or may not be illegal, you certainly are tempting the law of unintended consequences to place your butt squarely within a sling.

So... unless and until you have authorization, take this Dad's advice: We look with our eyes, not with our hands... keep your packets in your pockets.

-------------------------------------------------------------------
Tom Liston - Intelguardians
Keywords:
0 comment(s)

How to setup penetration testing exercises.

Published: 2006-03-02
Last Updated: 2006-03-02 03:59:55 UTC
by Johannes Ullrich (Version: 2)
0 comment(s)
Based on the many responses we got regarding the 'Packetslinger' diary, here a few notes on how to setup a penetration/cracking exercise.

As a remark: Laws change from area to area. Whatever you do, check your local laws and regulations. Corporate policies, university ethics guidelines and ISP contracts may have to be consulted.

  1. Avoid the use of public networks if possible. Its just too easy to 'fat finger' an IP address. It is all too easy to unintenionally shut down a critical system using an attack as simple as a portscan.
  2. If you have to use a public network, try to setup a VPN to isolate the sources and targets involved.
  3. Ask participants to remove or turn off additional network interfaces (in particular wireless interfaces).
Any attack, even as simple as a portscan, should only be performed with written permission. Even in a lab environment, it may be a good exercise to go through the motions of obtaining written permission from the instructor. It is not always easy to identify the person who has to provide permission. But in general, this should be the 'network owner'. Remember that part of a corporate network may be owned by an ISP, and not the company (or university).

Can you go to jail for running a portscan? Unlikely. But the fact that you consider this question is a good hint that you should get written permission. Internal teams may be given permission  via policy documents. See http://www.sans.org/resources/policies/ for templates (e.g. the Audit Vulnerability Scanning Policy or the Risk Assessment Policy).

Couple additions submitted by readers:

- Setup the entire network (attacking systems and targets) in vmware. Use RFC1918 addreess to avoid 'leakage' and firewall the test network. Students can ssh into the network. (Thanks Mike and Nick!)






Keywords:
0 comment(s)

Gmail javascript vulnerability (fixed)

Published: 2006-03-02
Last Updated: 2006-03-02 01:47:01 UTC
by Swa Frantzen (Version: 1)
0 comment(s)
Earlier today we received a report of a javascript vulnerability in gmail. We contacted Google and in the mean time they reported back on it being fixed. The issue seemed rather trivial to exploit.

Our Google contact also pointed out:
In the interest of minimizing the impact that security vulnerabilities have on our end users, we highly encourage anyone who discovers a vulnerability in a Google product or service to follow responsible disclosure policies by contacting us first at security/at/google/dot/com .

I'm sure most users of gmail would rather have security issues handled like they suggest above instead of having it published on some blog first, next some reader finding it and us finally doing the right thing.

Is it that much to ask to send it off to the vendor first ? Even if some vendors wait like forever, or take years to fix things. Not all of them are that way, so let's at the very least give them a heads-up warning.

And if you cannot find the address where to do it, we'll gladly help you search for it.

--
Swa Frantzen
Keywords:
0 comment(s)

Comments

Login here to join the discussion.


Diary Archives