Apple, in unit shipments, is the largest vendor of UNIX systems in the world. They may not be used in the same fashion, but Apple completely eclipses "unix/solaris/linux/bsd" in shipped units, in fact ridiculously so.
From the article
Microsoft is set to include its Services for Unix (SFU) add-on for Windows as an integral part of the next major release of the Windows server operating system, codenamed Longhorn and expected in 2008.
Oh really? That's fantastic, especially since it's something - by the article's own timeline - that won't be here for another four years.
Some analysts said the move could eventually sideline conventional Linux and Unix operating systems.
Someone must have a pretty fancy crystal ball to tell us what is and isn't going to "sidelined" four years in the future.
By including SFU in Windows, Microsoft could rapidly become the biggest supplier of Unix software if Longhorn proves a success, undermining traditional Unix vendors such as Sun, HP and IBM, as well as Linux vendors' enterprise offerings.
Um, someone is forgetting about the single largest shipper of UNIX* systems in the world: Apple, which eclipses all other vendors.
In fact, Microsoft's move is aimed at two things primarily: Linux and Mac OS X, both in the server environment and on the desktop. Both OSes are making serious and impressive inroads in areas where they've never had large showings: Linux on the desktop, and Mac OS X in the datacenter. Microsoft, of course, sees this - given Gates' recent diatribes about the "dangers" of anything open source, or anything non-Microsoft - and we can leave it up to brilliant journalists to spread FUD to help hawk a product that won't ship for almost half-a-decade.
Microsoft may also release a 64bit version of SFU this year.
Oh really? That's wonderful news, considering we've already got that support with various commercial and non-commercial *NIXes and Linux for quite a while. Again, Microsoft, with the aid of journalists, pulling the normal "hey, you might be able to do X now, but in a few years, you'll be able to do it with Windows Amazing Edition even better! So don't invest in anything else, just stay with the perennial safe refuge of Microsoft!"
Do the installation behind a personal NAT/firewall device.
(Or, read all the posts about how you can put together some huge, convoluted update CD that's never completely up-to-date instead of just spending $35 on a little hardware firewall.)
Nothing will happen to iChat, since this article has nothing to do with anything iChat, or current AIM users on any platform, can do. One-on-one text, audio, and video chat are not affected. This is a NEW service, for "business", that would be targetted at multiple-user videoconferences, integrating meeting technologies from Lightbridge and WebEx. They'll simply be using the AIM buddy list and presence system to initiate contact. Perhaps a new version of AIM will even integrate the feature. But it does NOT affect anything you can currently do with iChat and/or AIM.
Whether you think this is a sign of things to come - that AOL might start charging for formerly free AIM-related services in the future - is a different story...but that's extremely unlikely, since people currently use AIM from all sorts of devices, and would bail from AIM in droves. This proposed charge is for the NEW business-targetted conferencing and meeting services ONLY.
IBM's own literature (IBM PowerPC Quick Reference Guide - G224-7178-02) states the power dissipation of the 970 (130nm) and 970FX (90nm) are as follows:
Scaling the power (pdiss is proportional to operating frequency) to 2.5GHz for the 970FX leads to ~35W
A 2.5 GHz 970FX is lower power than a 1.8GHz 970. [...] The latest PowerBooks use the low power 7447A. From MPC7447AEC.pdf Rev. 0 2/2004
1267 MHz 18.3 W typical 1333 MHz 18 W typical (screened for lower power) 1420 MHz 20 W typical
...and multiple fans: Apple does it because they want to keep the machine as quiet as possible while still as cool as possible (as opposed to being forced to do it, lest the processor become hotter than the surface of the Sun).
(They don't do it because the PowerPC 970 family is "so hot", either; the PowerPC 970, and the 970FX even moreso, run much cooler, and require less power, than even the newest generation PowerPC 74xx (G4) family processors: )
Also, new PowerPC 970FX information from IBM is now available.
"In May 2003, the University of Wisconsin - Madison found that it was the recipient of a continuous large scale flood of inbound Internet traffic destined for one of the campus' public Network Time Protocol (NTP) servers. The flood traffic rate was hundreds-of-thousands of packets-per-second, and hundreds of megabits-per-second.
Subsequently, we have determined the sources of this flooding to be literally hundreds of thousands of real Internet hosts throughout the world. However, rather than having originated as a malicious distributed denial-of-service (DDoS) attack, the root cause is actually a serious flaw in the design of hundreds of thousands of one vendor's low-cost Internet products targeted for residential use. The unexpected behavior of these products presents a significant operational problem for UW-Madison for years to come.
This document includes the initial public disclosure of details of these products' serious design flaw. Furthermore, it discusses our ongoing, multifaceted approach toward the solution which involves the University, the products' manufacturer, the relevant Internet standards (RFCs), and the public Internet service and user communities."
"No word in given regarding how the average user should know whether or not to approve the request?"
Well, first of all, this security update takes the issue completely from the realm of a an automated exploit that could execute arbitrary code simply by visiting a web page with no user interaction or warning, to what can now only be described, more or less, as a social engineering exploit. If you download a new application, like, say an RSS reader, the OS will prompt you to add, for example, the 'feed:' URI handler:
- ONLY the first time, and
- ONLY if it's invoked remotely, e.g., via a web page, URL in an email message, etc.
And since the only value of this exploit came from it being used in two HTML frames with two META REFRESH tags, via a browser, to cause some type of remote volume to mount (or a file to download) AND then have the newly registered URI remotely called, this completely and totally fixes the issue, without hurting the normal functionality of having new URIs get registered when you launch an application. Saying "No word in given regarding how the average user should know whether or not to approve the request" is tantamount to saying that no guidance is given on whether or not a user should even know to open, say, a shareware app they've downloaded for the first time.
On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue. This addresses the core of the issue, which was several OS features interacting to essentially enable an automated exploit; that capability is now completely disabled. Apple even went further and removed some suspect handlers (disk:) completely, even though this fix makes it unnecessary.
Also, detailed information on what exactly was changed is here:
You're essentially looking to do the same thing many, many others have already done, and are doing every day, with Mac OS X in public lab-type environments. Do yourself a favor and visit
A Macintosh computer with Mac OS X v10.2.3 installed
A Department of Defense Common Access Card issued since 2001
An SCM Microsystems SCR331 USB High Speed EMV Reader
You can also use one of these smart card readers, but you must download and install driver software from the manufacturer's website:
"The PC/SC Workgroup is a collaborative effort of leading international personal computer and smart card companies, united to integrate their technologies under common standards. Apple is a Core Member of the PC/SC Workgroup along with Bull Personal Transaction Systems, Gemplus, Hewlett-Packard, Infineon, Intel, Microsoft, Schlumberger, Sun Microsystems and Toshiba.
PC/SC is a standard that builds upon existing industry smart card standards - ISO7816 and EMV - and complements them by defining low-level device interfaces and device-independent application APIs as well as resource management, to allow multiple applications to share smart card devices attached to a system.
The Smart Card Services SDK enables developers to write PC/SC-compliant applications and drivers on MacOSX starting with MacOSX 10.0.2.
The Smart Card Services SDK is available from Apple's Open Source repository. Access requires agreeing to the Apple Public Source License."
I've put up a test page at http://test.doit.wisc.edu/, and the exploit still works via afp, ftp, disk, and downloadable file in the default configuration of Mac OS X 10.3.4.
To protect yourself, you still MUST:
- disable "open safe files after download" in Safari
- disable the following protocols (or reassign to a helper other than Finder):
The original idea would be to place disk: mounted images into a non-executable sandbox.
Ok, but this still won't work, because disk:// isn't the only thing affected. The exploit can affect ANY type of network mounted volume: afp, smb, ftp, webdav, nfs, etc. Are you telling me that you shouldn't be able to execute anything from ANY network volume? That would break loads of things. (And also, even though the disk:-mounted-images-in-a-sandbox idea is invalidated because of this, just because you have never used disk: doesn't mean other don't.)
Therefore, consider a slightly scaled back version of my previous suggestion:
Don't allow URL/URI helpers to automatically register before execution of the application from network mounted volumes. I don't really see any other way to solve this. To reiterate: just making disk: mounted images non-executable sandboxes DOES NOT solve this problem; you'd have to make ALL network volumes non-executable sandboxes, and that simply will not work. If URL/URI helpers are disallowed from registering automatically from network volumes only, the problem is solved: this exploit is killed, but any apps on local volumes are allowed to register as usual.
The best idea I have heard so far was proposed somewhere else on this discussion thread. Simply make disk: mounted images non-executable. That would require the user to drag an application off the disk image to "somewhere else" and then execute it manually.
That's a really bad idea. This problem is easy to fix without losing functionality, or doing something stupid like disallowing execution on mounted disk images. The reason that's stupid is because this doesn't affect only 'disk:' mounted images: it affects afp, ftp, smb, webdav, nfs, and any method of mounting a volume. It's also really stupid because pretty much every single installer under the sun runs from a disk image. Having to copy it off first to even run it is a really, really, really bad idea because it would break the whole idea of disk images in the first place.
Fortunately, there's a simple fix: instead of letting registration of arbitrary handlers happen by LaunchServices *before* an application is even launched - which is the key to this exploit - Apple should only allow registration after an application is launched. This would require actual user interaction to specifically launch an application. That alone would protect against this exploit.
Some reports describe this as also a vulnerability with the 'disk' URI handler. This is incorrect. There is no vulnerability in the 'disk' URI handler; however, it could be used in conjunction with the 'help' vulnerability to deliver malicious content. On its own, 'disk://' does nothing more than enable the remote mounting of disk images. It was this capability combined with the 'help' vulnerability's ability to run arbitrary code at a known location that made it dangerous.
Also, reports have also described this as a vulnerability in Safari, Internet Explorer, or other browsers. This is also incorrect. It was a vulnerability in the way Help Viewer handles 'help' URI requests passed to it by the OS.
Last, there seems to be a misunderstanding that this vulnerability requires the OpnApp.scpt helper script within Help Viewer somehow. It does not. However, OpnApp.scpt, combined with the help URI handler vulnerability, could be used to execute some arbitrary commands. But "exploiting" it actually just comes back to general help URI handler vulnerability, now fixed.
That said, this was a very serious exploit...probably the first major (potentially) easily exploitable vulnerability for Mac OS X.
Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...
Last, the telnet:// "vulnerability" isn't really a dangerous one, since it can only overwrite files (not directories) with a known name and path that you have permission to, and only one file at that. Yes, yes, plenty of preferences and maybe even some really irritating things like your iTunes Music Library database file. In any event, this definitely should also be fixed.
Life after the oil crash
on
Out of Gas
·
· Score: 1
And remember, this is NOT JUST ABOUT "GAS" FOR TRANSPORTATION.
This isn't about someone buying a Hummer or a Suburban instead of a Civic Hybrid or riding their bike.
Almost EVERYTHING modern industrial society needs is based on petroleum-based products and cheap energy. Plastics, fertilizers, pesticides, food processing, medicine, water purification...everything comes back to cheap energy and/or petroleum/oil-based products.
This is an EXAMPLE of an AppleScript with a custom icon. It does nothing malicious. It does not spread. It does not delete files. It speaks and displays some dialog boxes. It's merely poking fun at Intego's sensationalist handling of these issues on Mac OS X, and their claims that these represent serious flaws in Mac OS X.
I wonder if Intego will protect against, and describe, this trojan...?
Perhaps they can make another press release hawking VirusBarrier.
The "trojan" is an AppleScript that speaks the text: "Muhahahaha. You have been owned by this elite trojan. Just kidding." It then displays a series of dialog boxes:
1. "OMG! it's another trojan for Mac OS X! Will Intego have to protect against this one too?"
2. "Intego's irresponsible sensationalism about non-issues is quite astounding."
3. "They make wild claims about 'serious weaknesses' in Mac OS X that simply aren't true, for the sake of hawking their product."
4. "AppleScripts and fake MP3s do not, nor will they ever, rise to the level of the mind-boggling number of completely remote exploits for Windows, requiring absolutely no user interaction, that plague millions of computers and cost billions of dollars of lost productivity."
5. "Mac OS X is intrinsically and fundamentally more secure, and more open to peer and community review."
6. "Social engineering problems, such as tricking a user into launching a fake Word installer that's really an AppleScript downloaded from a P2P network, don't reveal 'serious weaknesses' in Mac OS X."
7. "Intego would be well suited to selling snake oil at a two-bit carnival."
It then quits.
It has Intego's VirusBarrier X installer icon, and is named "VirusBarrier X Install.app".
(Note: this package is CLEARLY labeled as an example, and comes with a read me.)
I think what they meant to say is that they realized it's more important to keep OTHER Windows users safe. By allowing users of invalid copies of XP to patch, known vulnerabilities that might be exploited and used as points of attack against other Windows installations are addressed. It simply makes sense for them to do this.
While you're right that the agreement can be changed, this isn't more restrictive in any way, it's less.
Seven burns down from Ten on tracks you already own.
Think about that.
Actually, this is wrong. First, you can burn non-DRMed songs as many times as you want. Second, you also have unlimited burns of protected songs...BUT, you can only burn the *same playlist* 7 times. You can make a new playlist - with the songs in the exact same order - and burn another 7 times. As many times as you want. This restriction is simply to make it impractical to make 1000 copies of some new album you downloaded from iTunes with a CD recorder tower. You can still burn the music that you bought an unlimited number of times (which, incidentally, strips it of all DRM as well).
iTunes on Campus, which lets academic institutions site license iTunes Music Store content for their users delivered by Akamai's distributed network, which now not only includes over 700,000 songs from all 5 major labels and 450 independent labels, but also thousands of audiobooks, periodicals, and journals.
Also new is the ability to import unprotected WMA into iTunes, and an iPod update to support Apple Lossless Encoder.
It does not require optical. It works over normal FireWire. It supports Panasonic's 100 Mbps DV-HD (DVCPRO HD) codec.
1080i HD content can be moved between a Panasonic HD VTR and a computer via FireWire with no generation loss:
"With Panasonic's new, compact AJ-HD1200A DVCPRO HD VTR, 24fps or 60fps progressive scan material shot by Panasonic's AJ-HDC27 VariCam HD Cinema camera or 1080i studio / sports truck footage recorded by DVCPRO HD VTRs can be transferred via the VTR's IEEE 1394 interface directly into Final Cut Pro HD without generation loss. Once transferred, the material is instantly available for real-time editing operations. All footage maintains its camera-original quality, because the IEEE 1394 FireWire interface transfers the native DV-HD high definition files, as originally recorded on tape in the VTR or Varicam, directly to the Power Mac G4 or Power Mac G5 host computer's internal hard drive."
Slashdot Mirror
Apple, in unit shipments, is the largest vendor of UNIX systems in the world. They may not be used in the same fashion, but Apple completely eclipses "unix/solaris/linux/bsd" in shipped units, in fact ridiculously so.
"With the release of Mac OS X, Apple became the largest vendor of Unix in the world"
"There are over 5 million Mac OS X users, including scientists, animators, developers, and system administrators, making Apple the largest vendor of UNIX-based systems."
A lot more...
This has been common knowledge for a couple of years now.
From the article Microsoft is set to include its Services for Unix (SFU) add-on for Windows as an integral part of the next major release of the Windows server operating system, codenamed Longhorn and expected in 2008.
Oh really? That's fantastic, especially since it's something - by the article's own timeline - that won't be here for another four years.
Some analysts said the move could eventually sideline conventional Linux and Unix operating systems.
Someone must have a pretty fancy crystal ball to tell us what is and isn't going to "sidelined" four years in the future.
By including SFU in Windows, Microsoft could rapidly become the biggest supplier of Unix software if Longhorn proves a success, undermining traditional Unix vendors such as Sun, HP and IBM, as well as Linux vendors' enterprise offerings.
Um, someone is forgetting about the single largest shipper of UNIX* systems in the world: Apple, which eclipses all other vendors.
In fact, Microsoft's move is aimed at two things primarily: Linux and Mac OS X, both in the server environment and on the desktop. Both OSes are making serious and impressive inroads in areas where they've never had large showings: Linux on the desktop, and Mac OS X in the datacenter. Microsoft, of course, sees this - given Gates' recent diatribes about the "dangers" of anything open source, or anything non-Microsoft - and we can leave it up to brilliant journalists to spread FUD to help hawk a product that won't ship for almost half-a-decade.
Microsoft may also release a 64bit version of SFU this year.
Oh really? That's wonderful news, considering we've already got that support with various commercial and non-commercial *NIXes and Linux for quite a while. Again, Microsoft, with the aid of journalists, pulling the normal "hey, you might be able to do X now, but in a few years, you'll be able to do it with Windows Amazing Edition even better! So don't invest in anything else, just stay with the perennial safe refuge of Microsoft!"
* Yes, yes, "UNIX-like".
Do the installation behind a personal NAT/firewall device.
(Or, read all the posts about how you can put together some huge, convoluted update CD that's never completely up-to-date instead of just spending $35 on a little hardware firewall.)
Nothing will happen to iChat, since this article has nothing to do with anything iChat, or current AIM users on any platform, can do. One-on-one text, audio, and video chat are not affected. This is a NEW service, for "business", that would be targetted at multiple-user videoconferences, integrating meeting technologies from Lightbridge and WebEx. They'll simply be using the AIM buddy list and presence system to initiate contact. Perhaps a new version of AIM will even integrate the feature. But it does NOT affect anything you can currently do with iChat and/or AIM.
Whether you think this is a sign of things to come - that AOL might start charging for formerly free AIM-related services in the future - is a different story...but that's extremely unlikely, since people currently use AIM from all sorts of devices, and would bail from AIM in droves. This proposed charge is for the NEW business-targetted conferencing and meeting services ONLY.
(From Macintouch)
IBM's own literature (IBM PowerPC Quick Reference Guide - G224-7178-02) states the power dissipation of the 970 (130nm) and 970FX (90nm) are as follows:
970@1.8 Ghz 51W typical
970FX@1.4 GHz 12.3W typical
970FX@2 GHz 24.5W typical
Scaling the power (pdiss is proportional to operating frequency) to 2.5GHz for the 970FX leads to ~35W
A 2.5 GHz 970FX is lower power than a 1.8GHz 970. [...] The latest PowerBooks use the low power 7447A. From MPC7447AEC.pdf Rev. 0 2/2004
1267 MHz 18.3 W typical
1333 MHz 18 W typical (screened for lower power)
1420 MHz 20 W typical
...and multiple fans: Apple does it because they want to keep the machine as quiet as possible while still as cool as possible (as opposed to being forced to do it, lest the processor become hotter than the surface of the Sun).
(They don't do it because the PowerPC 970 family is "so hot", either; the PowerPC 970, and the 970FX even moreso, run much cooler, and require less power, than even the newest generation PowerPC 74xx (G4) family processors: )
Also, new PowerPC 970FX information from IBM is now available.
Flawed Routers Flood University of Wisconsin Internet Time Server
http://www.cs.wisc.edu/~plonka/netgear-sntp/
Abstract:
"In May 2003, the University of Wisconsin - Madison found that it was the recipient of a continuous large scale flood of inbound Internet traffic destined for one of the campus' public Network Time Protocol (NTP) servers. The flood traffic rate was hundreds-of-thousands of packets-per-second, and hundreds of megabits-per-second.
Subsequently, we have determined the sources of this flooding to be literally hundreds of thousands of real Internet hosts throughout the world. However, rather than having originated as a malicious distributed denial-of-service (DDoS) attack, the root cause is actually a serious flaw in the design of hundreds of thousands of one vendor's low-cost Internet products targeted for residential use. The unexpected behavior of these products presents a significant operational problem for UW-Madison for years to come.
This document includes the initial public disclosure of details of these products' serious design flaw. Furthermore, it discusses our ongoing, multifaceted approach toward the solution which involves the University, the products' manufacturer, the relevant Internet standards (RFCs), and the public Internet service and user communities."
"No word in given regarding how the average user should know whether or not to approve the request?"
...as well as a description of what exactly occurs if this situation is encountered:
Well, first of all, this security update takes the issue completely from the realm of a an automated exploit that could execute arbitrary code simply by visiting a web page with no user interaction or warning, to what can now only be described, more or less, as a social engineering exploit. If you download a new application, like, say an RSS reader, the OS will prompt you to add, for example, the 'feed:' URI handler:
- ONLY the first time, and
- ONLY if it's invoked remotely, e.g., via a web page, URL in an email message, etc.
And since the only value of this exploit came from it being used in two HTML frames with two META REFRESH tags, via a browser, to cause some type of remote volume to mount (or a file to download) AND then have the newly registered URI remotely called, this completely and totally fixes the issue, without hurting the normal functionality of having new URIs get registered when you launch an application. Saying "No word in given regarding how the average user should know whether or not to approve the request" is tantamount to saying that no guidance is given on whether or not a user should even know to open, say, a shareware app they've downloaded for the first time.
On the other hand, if a user is innocently visiting a web site and a dialog box all of a sudden appears prompting the user to accept that *an application* be run, I think it's pretty clear that this handles the issue. This addresses the core of the issue, which was several OS features interacting to essentially enable an automated exploit; that capability is now completely disabled. Apple even went further and removed some suspect handlers (disk:) completely, even though this fix makes it unnecessary.
Also, detailed information on what exactly was changed is here:
http://www.info.apple.com/kbnum/n61798
http://www.info.apple.com/kbnum/n25785
You can verify that these issues are fixed by using the following test site: http://test.doit.wisc.edu/
You're essentially looking to do the same thing many, many others have already done, and are doing every day, with Mac OS X in public lab-type environments. Do yourself a favor and visit
...particularly the documentation section.
http://macosxlabs.org/
Developer - Mac OS X Security
Apple Federal Smart Card Package Manual
"To use FSCP, you need the following:
A Macintosh computer with Mac OS X v10.2.3 installed
A Department of Defense Common Access Card issued since 2001
An SCM Microsystems SCR331 USB High Speed EMV Reader
You can also use one of these smart card readers, but you must download and install driver software from the manufacturer's website:
Gemplus GemPC430 USB Smart Card Reader
OMNIKEY CardMan Desktop USB 2020
Schlumberger Sema Reflex USB v.2 Reader or Reflex USB Lite Reader
Smart Card Services (PC/SC) SDK
"The PC/SC Workgroup is a collaborative effort of leading international personal computer and smart card companies, united to integrate their technologies under common standards. Apple is a Core Member of the PC/SC Workgroup along with Bull Personal Transaction Systems, Gemplus, Hewlett-Packard, Infineon, Intel, Microsoft, Schlumberger, Sun Microsystems and Toshiba.
PC/SC is a standard that builds upon existing industry smart card standards - ISO7816 and EMV - and complements them by defining low-level device interfaces and device-independent application APIs as well as resource management, to allow multiple applications to share smart card devices attached to a system.
The Smart Card Services SDK enables developers to write PC/SC-compliant applications and drivers on MacOSX starting with MacOSX 10.0.2.
The Smart Card Services SDK is available from Apple's Open Source repository. Access requires agreeing to the Apple Public Source License."
Apple already ships MySQL and JBoss with Mac OS X Server, and supports basic use (e.g., enabling, basic use) via free support channels, or advanced support of any aspect via Mac OS X Server Software Support products.
I've put up a test page at http://test.doit.wisc.edu/, and the exploit still works via afp, ftp, disk, and downloadable file in the default configuration of Mac OS X 10.3.4.
To protect yourself, you still MUST:
- disable "open safe files after download" in Safari
- disable the following protocols (or reassign to a helper other than Finder):
afp
ftp
disk
disks
and additionally:
telnet
ssh
and/or install Paranoid Android
Hopefully Apple will find a reasonable resolution for this soon.
The correct links for the US-administered GPS satellite constellation, known as NAVSTAR:
NAVSTAR GPS Joint Program Office - responsible for operational maintenance of NAVSTAR GPS equipment, services, and infrastructure
Interagency GPS Executive Board - executive management of NAVSTAR GPS
GPS fact sheet - US Air Force facts about NAVSTAR GPS
US Naval Observatory NAVSTAR GPS home page
Further information:
FAS GPS background info
Global Security GPS background info
The original idea would be to place disk: mounted images into a non-executable sandbox.
Ok, but this still won't work, because disk:// isn't the only thing affected. The exploit can affect ANY type of network mounted volume: afp, smb, ftp, webdav, nfs, etc. Are you telling me that you shouldn't be able to execute anything from ANY network volume? That would break loads of things. (And also, even though the disk:-mounted-images-in-a-sandbox idea is invalidated because of this, just because you have never used disk: doesn't mean other don't.)
Therefore, consider a slightly scaled back version of my previous suggestion:
Don't allow URL/URI helpers to automatically register before execution of the application from network mounted volumes. I don't really see any other way to solve this. To reiterate: just making disk: mounted images non-executable sandboxes DOES NOT solve this problem; you'd have to make ALL network volumes non-executable sandboxes, and that simply will not work. If URL/URI helpers are disallowed from registering automatically from network volumes only, the problem is solved: this exploit is killed, but any apps on local volumes are allowed to register as usual.
The best idea I have heard so far was proposed somewhere else on this discussion thread. Simply make disk: mounted images non-executable. That would require the user to drag an application off the disk image to "somewhere else" and then execute it manually.
That's a really bad idea. This problem is easy to fix without losing functionality, or doing something stupid like disallowing execution on mounted disk images. The reason that's stupid is because this doesn't affect only 'disk:' mounted images: it affects afp, ftp, smb, webdav, nfs, and any method of mounting a volume. It's also really stupid because pretty much every single installer under the sun runs from a disk image. Having to copy it off first to even run it is a really, really, really bad idea because it would break the whole idea of disk images in the first place.
Fortunately, there's a simple fix: instead of letting registration of arbitrary handlers happen by LaunchServices *before* an application is even launched - which is the key to this exploit - Apple should only allow registration after an application is launched. This would require actual user interaction to specifically launch an application. That alone would protect against this exploit.
Some notes about the now-fixed exploit:
Some reports describe this as also a vulnerability with the 'disk' URI handler. This is incorrect. There is no vulnerability in the 'disk' URI handler; however, it could be used in conjunction with the 'help' vulnerability to deliver malicious content. On its own, 'disk://' does nothing more than enable the remote mounting of disk images. It was this capability combined with the 'help' vulnerability's ability to run arbitrary code at a known location that made it dangerous.
Also, reports have also described this as a vulnerability in Safari, Internet Explorer, or other browsers. This is also incorrect. It was a vulnerability in the way Help Viewer handles 'help' URI requests passed to it by the OS.
Last, there seems to be a misunderstanding that this vulnerability requires the OpnApp.scpt helper script within Help Viewer somehow. It does not. However, OpnApp.scpt, combined with the help URI handler vulnerability, could be used to execute some arbitrary commands. But "exploiting" it actually just comes back to general help URI handler vulnerability, now fixed.
That said, this was a very serious exploit...probably the first major (potentially) easily exploitable vulnerability for Mac OS X.
Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...
Last, the telnet:// "vulnerability" isn't really a dangerous one, since it can only overwrite files (not directories) with a known name and path that you have permission to, and only one file at that. Yes, yes, plenty of preferences and maybe even some really irritating things like your iTunes Music Library database file. In any event, this definitely should also be fixed.
http://www.lifeaftertheoilcrash.net/
Ignore the book advertisements. Just read the front page.
http://peakoil.net/
And remember, this is NOT JUST ABOUT "GAS" FOR TRANSPORTATION.
This isn't about someone buying a Hummer or a Suburban instead of a Civic Hybrid or riding their bike.
Almost EVERYTHING modern industrial society needs is based on petroleum-based products and cheap energy. Plastics, fertilizers, pesticides, food processing, medicine, water purification...everything comes back to cheap energy and/or petroleum/oil-based products.
we spend OVER 50% of our budget on "defense"
Bullshit
http://das.doit.wisc.edu/misc/outlays.jpg
Defense spending, INCLUDING veterans affairs and foreign affairs, is 20%. Nice try.
We spend more on "social programs" alone, and twice as much on social security and medicare.
Not saying defense spending still isn't a lot, but it's no where near "over 50%".
From the read me:
Trojan Example Read Me
This is an EXAMPLE of an AppleScript with a custom icon. It does nothing malicious. It does not spread. It does not delete files. It speaks and displays some dialog boxes. It's merely poking fun at Intego's sensationalist handling of these issues on Mac OS X, and their claims that these represent serious flaws in Mac OS X.
I wonder if Intego will protect against, and describe, this trojan...?
Perhaps they can make another press release hawking VirusBarrier.
For more information:
das@doit.wisc.edu
Available at:
http://mirror.services.wisc.edu/mirrors/tmp/
The "trojan" is an AppleScript that speaks the text: "Muhahahaha. You have been owned by this elite trojan. Just kidding." It then displays a series of dialog boxes:
1. "OMG! it's another trojan for Mac OS X! Will Intego have to protect against this one too?"
2. "Intego's irresponsible sensationalism about non-issues is quite astounding."
3. "They make wild claims about 'serious weaknesses' in Mac OS X that simply aren't true, for the sake of hawking their product."
4. "AppleScripts and fake MP3s do not, nor will they ever, rise to the level of the mind-boggling number of completely remote exploits for Windows, requiring absolutely no user interaction, that plague millions of computers and cost billions of dollars of lost productivity."
5. "Mac OS X is intrinsically and fundamentally more secure, and more open to peer and community review."
6. "Social engineering problems, such as tricking a user into launching a fake Word installer that's really an AppleScript downloaded from a P2P network, don't reveal 'serious weaknesses' in Mac OS X."
7. "Intego would be well suited to selling snake oil at a two-bit carnival."
It then quits.
It has Intego's VirusBarrier X installer icon, and is named "VirusBarrier X Install.app".
(Note: this package is CLEARLY labeled as an example, and comes with a read me.)
I think what they meant to say is that they realized it's more important to keep OTHER Windows users safe. By allowing users of invalid copies of XP to patch, known vulnerabilities that might be exploited and used as points of attack against other Windows installations are addressed. It simply makes sense for them to do this.
While you're right that the agreement can be changed, this isn't more restrictive in any way, it's less.
Seven burns down from Ten on tracks you already own. Think about that.
Actually, this is wrong. First, you can burn non-DRMed songs as many times as you want. Second, you also have unlimited burns of protected songs...BUT, you can only burn the *same playlist* 7 times. You can make a new playlist - with the songs in the exact same order - and burn another 7 times. As many times as you want. This restriction is simply to make it impractical to make 1000 copies of some new album you downloaded from iTunes with a CD recorder tower. You can still burn the music that you bought an unlimited number of times (which, incidentally, strips it of all DRM as well).
http://www.apple.com/education/itunesoncampus/
iTunes on Campus, which lets academic institutions site license iTunes Music Store content for their users delivered by Akamai's distributed network, which now not only includes over 700,000 songs from all 5 major labels and 450 independent labels, but also thousands of audiobooks, periodicals, and journals.
Also new is the ability to import unprotected WMA into iTunes, and an iPod update to support Apple Lossless Encoder.
And last, iMovie 4.0.1 has been released.
Fuck the motorbike; can I ride her?
Isn't that what happens in Soviet Ru...?
Oh, never mind.
It does not require optical. It works over normal FireWire. It supports Panasonic's 100 Mbps DV-HD (DVCPRO HD) codec.
1080i HD content can be moved between a Panasonic HD VTR and a computer via FireWire with no generation loss:
"With Panasonic's new, compact AJ-HD1200A DVCPRO HD VTR, 24fps or 60fps progressive scan material shot by Panasonic's AJ-HDC27 VariCam HD Cinema camera or 1080i studio / sports truck footage recorded by DVCPRO HD VTRs can be transferred via the VTR's IEEE 1394 interface directly into Final Cut Pro HD without generation loss. Once transferred, the material is instantly available for real-time editing operations. All footage maintains its camera-original quality, because the IEEE 1394 FireWire interface transfers the native DV-HD high definition files, as originally recorded on tape in the VTR or Varicam, directly to the Power Mac G4 or Power Mac G5 host computer's internal hard drive."
Read the joint Apple/Panasonic press release