Last Updated: 2006-03-02 18:27:17 UTC
by Swa Frantzen (Version: 2)
Apple released a security update called "2006-001". It is claiming to update following components:
CVE-2005-3319, CVE-2005-3353, CVE-2005-3391, CVE-2005-3392
- Directory Services
CVE-2006-0390/CVE-2005-4504, CVE-2006-0387, CVE-2006-0388, CVE-2006-0394
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:
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)
Last Updated: 2006-03-02 16:55:36 UTC
by Tom Liston (Version: 1)
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:
- 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.)
- 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.
- 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?
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
Last Updated: 2006-03-02 03:59:55 UTC
by Johannes Ullrich (Version: 2)
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.
- 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.
- If you have to use a public network, try to setup a VPN to isolate the sources and targets involved.
- Ask participants to remove or turn off additional network interfaces (in particular wireless interfaces).
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!)
Last Updated: 2006-03-02 01:47:01 UTC
by Swa Frantzen (Version: 1)
Our Google contact also pointed out:
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.