The BBC has an article about the cracking of Microsoft’s DRM protections for Windows Media format files.
As I’ve mentioned before, “DRM works in exactly one scenario: when the owner of the rights also controls the behaviour of those subject to DRM”.
Because the music producers have no effective recourse to punish music purchasers for software they might install on their systems, or changes they might make to data, there is effectively no barrier to the purchasers’ ability to circumvent DRM – it may be merely a matter of intercepting the DRM software at a point after it has accepted the licence, and saving that state.
Personally, I believe that this is a good thing – when you sell me software or music, I should be able to move that software or music from one medium to another, so that I don’t end up with the situation I complained about last month, of having to find a way to get a duplicate of something that the manufacturer no longer wishes to sell me (but which I still have rights to possess).
DRM for the home is doomed to failure – over and over again.
I’ll predict it now – whatever change Microsoft makes to their DRM to overcome this, it will either be hopelessly intolerable to use, or it will be broken inside of a year – and there will be a new news item on the topic.
We all make mistakes, and I made a mistake in a piece of code buried deep within WFTPD.
[Actually, I’ve made several mistakes, and there are certain to be a few I’ve yet to find.]
As a result, some sociopath has been able to release an “exploit” – a program that can be run against the WFTPD server that allows it to be broken into.
[Actually, the sociopath is not the first person to discover the flaw – “appsec.ch” notified me last month, and I’ve been bringing the new code up to scratch and testing it every spare minute since then, as well as testing workarounds.]
There’s never a good time to have a public disclosure of a vulnerability in your software, but the timing of most public disclosure addicts is impeccable – Thanksgiving, Christmas, weekends, vacations, these are all the most likely times for posting exploits, because that way, they can be distributed to the largest number of bad hackers, at a time when the fewest users will be looking for fixes.
This time, the exploit has come out at a time when we are in a spat with our ISP, 1&1 – they have disabled our password-protected directory support, so we aren’t able to provide downloads of registered software right now.
The best you can hope for with a vulnerability is that there is a workaround, while such issues are resolved, new versions are tested and before the final software can be deployed.
Sure enough, we have a workaround here.
For WFTPD Server, you will need to edit the WFTPD.INI file. In the “[Server]” section, add a line that reads “GFPNMethod=0“
For WFTPD Pro Server, edit the registry under “HKEY_LOCAL_MACHINE\Software\Texas Imperial Software\WFTPDPro\Servers\<ServerName>” [replace “<ServerName>” with the name of the server you’re editing – you will have to do this for each server]. Add a DWORD key called “GFPNMethod” and set its value (either decimal or hexadecimal) to 0.
Here’s the important part – restart WFTPD Server or the WFTPD Pro service (depending on whether you have WFTPD Server or WFTPD Pro Server). This is one of those rare settings that is loaded only when the server is first loaded from the registry.
The truly paranoid will want to restart the machine, just to be “safe”.
Once we get our ISP replaced, we’ll be shipping a new version, 3.24. In the meantime, please use the workaround listed above.
Okay, so apparently, I was a tad optimistic in saying that I had solved my hibernation issues on my laptop by simply disabling and then re-enabling the hibernation feature (which did have the desired effect of building a larger hiberfil.sys file).
As it turns out, Microsoft have this one covered – in a manner of speaking. There’s a knowledge base that addresses exactly this problem – apparently, after you install more than 1GB of memory into a machine running Windows XP, it may occasionally (every damn time) refuse to hibernate, citing “Application Popup: Windows – System Error : Insufficient System Resources exist to complete the API” in the System Event log.
Meaningless as that message is, it apparently comes from a requirement to have an area of contiguous free memory, a somewhat ludicrous proposition on a heavily-loaded operating system, such as you might get when running a memory pig such as Outlook or Outlook Express.
The KB (Knowledge Base) item referred to above is of great help, however, because it describes a hotfix that is available.
All hotfixes are available free from Microsoft, no matter what your contract is with them. Here’s a description of how my call for a hotfix went:
Wow – that was really hard – NOT. Twelve minutes on the phone, two of which were me telling the occupants of the room I was in to “shut up, I’m on the phone”. To resolve an issue that causes me such irritation, ten minutes of time is well worth it.
Part three of this series will be me installing the hotfix and seeing if it works for me.
I’d like to give my readers a description of some basic things you can do in order to protect your laptop.
The first thing you can do is to itemise the risks that concern you. Here’s my risks list:
So, what are my mitigations?
So, what’s the absolute minimum? 1, 2, 4, 5 – but then again, that’s really not enough. I think they’re all part of the “absolute minimum”. Ask yourself the same “what’s my risk?” question – always ask that question when faced with a security debate – and see what you come up with as an absolute minimum.
I’d love to hear what you come up with.
I’m trying out a new Blog posting tool, Windows Live Writer, currently available in beta test version.
I spend a lot of time disconnected from the Internet, and I frequently get irritated that I haven’t found a tool that I can use to update my web site over lunch, on the bus, in the coffee bar (yeah, like I’m paying their ridiculous rates!)
It doesn’t take much, just the ability to preview what you’re typing, edit the HTML to get rid of whatever craziness the editor puts in that I don’t want, and some ability to add graphics, links, etc.
[Okay, so the graphics didn’t work with my blog’s configuration. But I’m sure we can change that.]
It also helps that I can download and edit existing posts that were posted with any other tool, and the Web Page Preview is great – even when you’re offline, you can see how your post will look once you’ve posted it.
Give Windows Live Writer a try – it gives me the impression of being about as simple as it needs to be – which is extremely high praise!
I’ve suggested for a long time that developers should spend some time on technical support to find out how their customers use the product – not just to get the numbers of “this is our most called-about issue”, but to get an idea of what their target audience really is.
But then, to go with Larry’s argument, tech support and development are two separate skills, and it would seem like a bad idea to do this, because good developers might not be good on tech support, and vice versa.
You can only take this so far, I think – at some point, everyone you employ has to be able to work outside of his or her comfort zone. Take into account that this is not their best side, perhaps, but recognise that the individual will learn far more, and be more useful back in their main role, if they learn something of the world with which their code will interface.
I’ve met too many developers who were developing for a target market that didn’t exist except for a few “powerhouse” customers who could afford to send bullying representatives to persuade the program management team that their desired features were the only ones worth implementing. That’s a great way to satisfy your “powerhouse” customers, but not a great way to build a wide business base.
I think it’s important for developers to understand something of the level “above” and “below” the software they work on. Most developers agree that they need to understand the level “below” their software – understanding the compiler and assembly language, and even a little of how the processor works on code, will generally help you write more efficient code.
But you have to understand something of the users you’re developing for, for the same reason – it will help you write more efficient code for them.
Taken to another direction, you have to understand something of the developers before and after you, in order to continue a chain of maintenance on the code (be prepared to read code with no good comments, but make sure you comment your code – ideally inside the code itself – for the developer to come after you).
Too many developers that I’ve worked with in the past tended to act as if they needed to know nothing about their potential users – “if you build it, they will come”, kind of attitude. That’s fine if you have a captive customer base, but if you want to be competitive, you have to know who you’re aiming for, and target them at all levels – including the developers.
So, yeah, developers shouldn’t be your ops department, or your tech support department, but they should be familiar enough with those departments that they do not generate strife for them, and so that they understand the departments enough to offer solutions that the others do not see.
More laptop encryption news:
“A U.S. government computer loaded with approximately 133,000 drivers’ and pilots’ records — including Social Security numbers — was stolen last month, the Department of Transportation said Wednesday.”
I’ve also been asked about the recent story of the VA losing(*) 38,000 records. This is actually a very different story, for the following three reasons:
See, totally different.
In related news, of course, with today being August 9th, 2006, all government laptops have been encrypted for two days now, and so we won’t see any more of these stories going forward, right? <FX: Crickets/>
(*) By “losing”, of course, I don’t mean that they don’t still have the data, they’ve merely widened its distribution to include unknown and untrusted third parties. Oh, and someone apparently walked away from their offices with a desktop!
(**) Conslutant derives from three root words – “con” meaning to fool you, “sult” meaning someone who’ll tell you you’re clever and handsome for as long as you have money, and “ant”, meaning a small insect.
Initial impressions… “Holy crap!”
06-040 – install this sucker unless you block the usual RPC ports internally and externally.
06-041 – install this unless you never use DNS to external servers, or can apply the workarounds.
06-042 – install this on any machine that runs Internet Explorer. Then install it on the ones that don’t yet.
06-043 – if you use OE6, install it. What the heck, it doesn’t cause a restart, so (make sure you’re not running OE6 right now, and then) install it anyway.
06-044 – install on any machine that runs Internet Explorer – see 06-042.
06-045 – install on any machine – don’t be fooled by the “Important” rating, derived from the requirement that a user must click on an email or attachment or web page – users click on anything.
06-046 – install this. HTML Help is everywhere (thanks, Microsoft!)
06-047 – install this if you use Office, or anything that runs VBA.
06-048 – install this if you use Powerpoint.
06-049 – install this if your users are really sneaky and horrible. Do you trust your users?
06-050 – install this – it’s all about protecting against users clicking on hyperlinks. see 06-049.
06-051 – install this.
Okay, so I can’t believe I’m defending Apple in this post.
He starts with a point I can get behind – that it’s hardly sporting to give a demonstration of an exploit using a video – it’s like demonstrating a piece of software with a screenshot. There’s no feel for “yes, I really saw that happen”.
On the other hand, I can also get behind the researchers’ reasoning for not demonstrating the exploit live – in an auditorium filled with WiFi-enabled notebooks, you’re not going to be popular if you launch an exploit that takes down even 10% of the audience. Funny, yes. Popular, no. Appropriate, definitely not.
Joe comes up with a really catchy term for this, “faux disclosure”. Not that this is really any different from someone who posts news of an exploit without any accompanying code – which is a pretty responsible way to publicly disclose a vulnerability prior to its being patched, in my opinion.
But the really offensive part comes later:
I asked Lynn Fox, Apple’s director of Mac public relations, two very direct questions.
1. Are Apple MacBook users at risk using their built-in Wi-Fi capability?
2. Is Krebs’ Washington Post report about Apple pressuring researchers not to reveal a MacBook Wi-Fi vulnerability/exploit accurate?
I’ve received no response to that query. Nor do I expect one.
And of course, “Apple pressuring researchers” could be as savage as the security response team at Apple (they have one, yes?) asking the researchers to hold off publishing details until they have a patch together. “Think of the users,” I’m sure they’d say – damn, that’s pressure. OK, so maybe there’s more to it than that, but we have no reason to believe so.
Since this is all speculation and rumour, it’s really no surprise that anyone is willing to confirm anything – and that’s just what you need to feed a good conspiracy theory. A good slice of silence practically confirms the best kind of fear, uncertainty and doubt (FUD). A smart listener can learn to understand that silence, or “I refuse to dignify that question with an answer” sometimes means only that the question, or the questioner, is not worth answering.
And as for an earlier comment in his article – “what is meant by full disclosure these days” – notifying the vendor before notifying the world (which, clearly, contains, as a subset, all the hackers, crackers and script juvies in the world, as well as all the users) – boy, that really tips the wink as to which side this poster is on – he wants to punish the vendors, and it doesn’t matter to Joe who gets hurt along the way.
A mature response is to do whatever it takes to protect the users, now and in the future. If punishing the vendor is the only way to protect the user, then so be it – but it seems like we left that back some time closer to the last century. If assisting the vendor is the best way to protect the users, then assist the vendor, no matter how repugnant they are to you.
Joe Barr needs to mature a little. Grow up.
[Updated to reference Microsoft article on non-broadcast wireless networking]
I read an article the other day in Information Week, by Preston Galla. The name rang a bell, and I remembered that he used to review shareware for ZDNet. The fact that I remember his name suggests that I disagreed strongly with what he wrote about my software 🙂
The article basically says that you can secure wireless networks by a few simple steps:
Let’s contrast that with a ZDNet blog article by George Ou on “The Six Dumbest Ways to secure a Wireless LAN“, along with a quick parenthetical summarisation of what I believe George is saying:
Dishonourable mention: WEP encryption – “it takes only a few minutes to break a WEP based network which makes WEP completely ineffective”.
I make that three out of six of Preston’s recommendations on how to secure wireless networks line up in George Ou’s “dumbest six ways”. I have to agree with George.
The DHCP one is a classic – to try and limit the hackers, you make it easier for them to engage in a denial of service attack on you?
Even Microsoft, a company known for allowing people to make decisions that don’t exactly help security (hello, account lockout?) without comment, has documentation on disabling SSID broadcast as being a bad idea – note the tone of the article says “we’re trying to make it easier to do this, but really, it’s a bad idea to begin with”.