From paul.suh at ps-enable.com Wed Feb 7 10:25:58 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Wed Feb 7 10:23:59 2007 Subject: [Newsletter] Why DRM can never succeed Message-ID: Folks, Steve Jobs' statement on music and DRM came out yesterday, neatly dovetailing with a piece I wrote last week. I intended to send it out next week on my regular schedule, but since it's very timely I thought I would just send it out early. I read an interesting article on the International Herald Tribune web site via Slashdot: Are the record companies finally giving up? I don't know, but I can tell you that in the long run Digital Rights Management software cannot succeed. Why? It has to do with a combination of economics and technology. Let's start with the economics of DRM. DRM-protected content doesn't just get played back on computers, it also gets played back on portable consumer electronic devices like DVD players and iPods. Thus, the DRM has to be lightweight enough to be implemented in a chip that can be sold as a part of a consumer electronics device. For instance, the DRM for a DVD player cannot use a full-blown modern CPU, it has to function on a chip that can be sold for no more than $10 or so and that can function (in the case of a portable device) on a tiny fraction of the power budget. Otherwise, the DVD player manufacturer will not be able to sell the DVD player at a profit in today's marketplace. The DRM had to do the same work on a chip of not- too-much-higher cost (maybe $50) *years* ago. How much processing power does such a chip have? Not a lot. Making the protection algorithm any stronger would require a more costly, power-hungry CPU and make the DRM impractical. Furthermore, media formats for consumer electronics devices need to last at least a decade. Otherwise, consumers will perceive the format as a ripoff and not buy the media -- look at what happened to the original DivX format. What happens when the wimpy DRM that is feasible on a portable consumer electronics device runs into a general purpose computer five or six years after the DRM format comes into use? Well, to start with, a general purpose CPU that was a contemporary of the original DRM chip probably had a couple of orders of magnitude more processing power. Then, the current general purpose CPU will benefit from three or four generations of Moore's Law, so add on several more orders of magnitude of processing power. The general purpose CPU will be able to crack the DRM hundreds of thousands of times faster than the little built-in chip. If that weren't enough, the DRM can be attacked by a network of multi-core CPU's operating in parallel, a la the SETI@Home project. Remember, the DRM has to be cracked just once and the content is accessible to everyone. As time marches on, the economics of the problem just get worse. Consumers expect devices to get cheaper and thus less money is available to implement a strong DRM scheme. The attitude within Apple towards DRM seems to be somewhere between thinly veiled contempt and sourness at a necessary but very disliked evil. No one will say it from Apple for the record, but if the record companies would agree to drop DRM requirements, the iTunes Store would switch to DRM-less AAC's in a heartbeat. DRM just raises costs for Apple, and provides little benefit. Apple makes its money on iPod sales, not on song sales. The cost of maintaining the FairPlay DRM code for song sales on the server and in iTunes/QuickTime is a drain that gives no benefit to Apple. OK, I wrote that last paragraph a week before Steve Jobs himself posted his thoughts on Apple's website. Mr. Jobs himself has stated for the record that DRM does nothing for Apple, is not a part of a lock-in strategy, and would be history in a second if the record companies would agree to let Apple drop it. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : http://mail.goodeast.com/pipermail/newsletter/attachments/20070207/2f81a57c/smime.bin From paul.suh at ps-enable.com Wed Feb 14 15:17:00 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Wed Feb 14 15:17:11 2007 Subject: [Newsletter] Movie in Setup Assistant, VPN Protocol Network Ports, Snow and Ice Message-ID: Folks, I sent part of this week's newsletter out last week, so this one is a little bit light. Cut Out the Movie in Setup Assistant One of the more annoying things in setting up Mac OS X is the QuickTime movie that plays when the Setup Assistant runs. The first time, it's kinda neat, but by the tenth time it's getting old and by the twentieth time you're thinking, "enough, already!" You can't do anything with the default install DVD, but if you are building a custom install image then you can cut these out or replace them by changing two files on your image: /System/Library/CoreServices/Setup Assistant.app/Contents/Resources/ TransitionSection.bundle/Contents/Resources/intro.mov /System/Library/CoreServices/Setup Assistant.app/Contents/Resources/ TransitionSection.bundle/Contents/Resources/intro-sound.mp3 The first is the movie that plays, the second is the sound track. I haven't tried deleting them entirely, but it's easy enough to cut them down to a second or so using QuickTime Player Pro. Alternatively, you can replace them with a movie and sound that is customized for your organization. VPN Protocol Network Ports I was investigating a VPN problem for another consultant, and thought that some of the information I used as a part of the investigation might be of interest to folks. Mac OS X Server has two VPN protocols, PPTP (Point-to-Point Tunneling Protocol) and L2TP (Layer 2 Tunneling Protocol, technically, L2TP over IPSec). PPTP uses port 1723 TCP and the GRE protocol as well. GRE is IP protocol 47 -- this is at a network layer similar to TCP or UDP. By way of comparison, TCP is IP protocol 6 and UDP is IP protocol 17. See for a list of all of the various protocols. The router must be set to pass *both* TCP port 1723 and GRE to the VPN server, or the VPN will fail. L2TP uses ports 500, 1701, and 4500 UDP, and the ESP protocol (IP protocol 50). 4500 is not strictly necessary as it is only used if the VPN traverses a NAT layer, but it doesn't hurt anything to turn it on at the router. Again, the router must be set to pass both the UDP ports *and* the ESP protocol to the server. Snow and Ice I just finished shoveling the sidewalk and driveway in front of our house. We got about three inches of snow plus freezing rain, which made for very heavy, wet, hard-to-shovel stuff. We didn't lose power this time, but I think this is a good reminder for all of us to think through what is acceptable in terms of unplanned outages for our organizations. What do the various levels of reliability translate to? 99% uptime = 3 days 16 hours unplanned downtime per year 99.9% uptime = 8 hours 45 minutes unplanned downtime per year 99.99% uptime = 53 minutes unplanned downtime per year 99.999% uptime = 5 minutes unplanned downtime per year Each time you add a 9, figure on increasing your costs by an order of magnitude. How critical are computers to your operations? What systems need the full five nines treatment and what systems can get by with lesser uptime needs? Another way to look at it was written about by the software company FWB back in the early nineties. (Some of you may remember them for their disk and backup utilities, which were excellent for their time.) They called it the rule of twos, with respect to downtime: 2 seconds - Full clustered environment with automatic failover 2 minutes - Spare equipment ready to go - just turn it on 2 hours - Spare equipment is set up but not plugged in - take it out of the closet, plug it in, turn it on 2 days - Spare equipment is on-site but not set up - take it out of the box, set it up, plug it in, turn it on 2 weeks - No spares on-site, need to order equipment and wait for it to arrive Here, decreasing the recovery time increases costs by an order of magnitude at each step. A monkey wrench in all such calculations are systems that change in priority depending on the time of day or time of year. A computer in a classroom used for a games and drills may be a 2 week machine most of the time, but what if you need it for No Child Left Behind testing this week? Is your Point-of-Sale computer system a 2 hour system most of the time, but a 2 minute system the day after Thanksgiving? Just some food for thought. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : http://mail.goodeast.com/pipermail/newsletter/attachments/20070214/49d0305d/smime.bin From paul.suh at ps-enable.com Mon Feb 26 21:36:15 2007 From: paul.suh at ps-enable.com (Paul Suh) Date: Mon Feb 26 21:36:28 2007 Subject: [Newsletter] The Month of Apple Bugs Analyzed Message-ID: Folks, So now that the Month of Apple Bugs project is over, how many of them were really ones we should worry about? To jump ahead to the punch line, only one bug is problematic, and even that one requires that the user take a positive action. It can't just happen to an otherwise idle machine, or be triggered just by looking at an e-mail or web page. Even that last one can be patched by a sysadmin so that it can be neutralized even before Apple releases an official patch. Bugs by the Numbers ----------------------------- So, let's look at what constitute worrisome bugs, i.e. ones that would give potential root-level access, in order of increasing severity: 1) A bug in a third-party application - 4 (#'s 2, 7, 16, and 19) With a few very rare exceptions, these are the hardest for an attacker to exploit since there is no guarantee that any particular machine will have the application installed. Most of the time a user can easily switch to an alternative application with little or no loss of functionality. 2) A bug in a third-party system extension - 3 (#'s 8, 18, and 27) These are things that install kernel extensions and root-level daemons. Easier to exploit since they work at a lower level than user applications, but again many if not most users will not have these installed and most users can switch away to a different extension or daemon. 3) A bug that requires action by an admin user - 14 (#'s 1, 3, 4, 5, 6, 9, 10, 11, 15, 20, 23, 24, 26, and 28) These are vulnerabilities that require an admin user who is logged in to the Mac to take some positive action like clicking on a link or running an application. Running as a standard user makes these a non- issue. 4) A bug that requires local access but no action by an admin user - 0 These are vulnerabilities that require that an admin user be logged in, but not take deliberate action to trigger the bug. An example would be a bug in WebKit where simply viewing an HTML-formatted e- mail triggers the vulnerability. Many Outlook worms on Windows spread this way. 5) A bug that requires local access by a standard user - 3 (#'s 12, 21, and 22) Like category 3, but running as a standard user does not protect against them. 6) A bug that requires local access but no action by a standard user - 0 Like category 4, but running as a standard user does not protect against them. 7) A bug that requires network access via a protocol that is off by default - 2 (#'s 14 and 17) These are more dangerous, in that the machine only has to be on with the sharing protocol turned on. No one has to be logged in. However, the network protocols associated with this category of vulnerabilities are turned off by default. 8) A bug that requires network access via a protocol that is on by default - 0 Same as category 7, but the network protocols are on by default. Comments on the Bugs -------------------------------- Bug 21 - System Preferences writeconfig Local Privilege Escalation Vulnerability - The preference panes setuid helper, writeconfig, makes use of a shell script which lacks of PATH sanitization, allowing users to execute arbitrary binaries under root privileges. This one is a case of really bad programming practice by Apple. Anything executing as root should not run a shell script as a sub- process in the first place. Bugs 12, 13, 25, 29, 30 - These are denial of service bugs that don't lead to code execution. While annoying and potentially worrisome as a part of a more sophisticated attack, none of them are by themselves serious security threats. Bug 31 - This one has not been released, so it's hard to say what it's worth. It is presented as a kernel vulnerability, potentially the most severe category of threat. In most cases the courteous thing to do is to give the vendor a chance to release a patch for the bug before disclosing it. On the other hand, the MoAB people have not been shy about disclosing other potentially serious bugs, so why should they delay on this one? Conclusions ----------------- I would say that Apple came off pretty well in this month of bugs. Seven out of 30 are not even Apple's problem, leaving only 23. Five more are denial of service and not code execution, leaving only 18. Of the 18, *none* can be exploited without some sort of positive user action -- opening a file, clicking a link, or turning on a service. Running as a standard user eliminates 14 of the bugs, leaving only four, or even two if you don't have the vulnerable services turned on. Does this mean that you can ignore Mac security? Of course not. However, it shows that a Mac faces a relatively low security threat level. First, if you've followed my advice you are running as standard user and have all unnecessary services turned off. This means that you are only open to three of the bugs. Second, since the Mac has so many fewer vulnerabilities, the *propagation rate* of a piece of malware is vastly slowed, giving sysadmins and Apple time to put up defenses. Here is one case where a biological analogy is actually useful -- it's the difference between the spread of a disease in a population that is partially vaccinated vs. one that is unvaccinated. Even though only some of the population is immune, that is enough to slow the spread of the disease so that public health authorities can get ahead of the curve and stop the epidemic easily. FYI, Apple has patched bug #1 in Security Update 2007-001 and #'s 9, 20, 22, and 29 in Security Update 2007-002, leaving only one (#21) that is truly troublesome. If you follow the procedure in then you can neutralize this last bug. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : http://mail.goodeast.com/pipermail/newsletter/attachments/20070226/fc660d04/smime.bin