Follow-up on April security bulletins and some news

OK, I just approved the DL’s for the April security bulletins - expect to see them live later today or tomorrow.  I apologize for the long delay on this – my web release guys were swamped last week, due to two factors:  first, it was Security Bulletin time around here; and second, last week was spring break for the local school systems and lots of people had vacation planned with their families.  I realize this looks like a step backward as far as the time lag goes, but for the desktop updates, nothing really has changed process-wise – we did this release just as we have over the past year.  However, as we move the process forward and get it better settled into WinSE, I expect to be able to get the releases moving sooner, which means they’ll appear on the OEM Secure Site sooner.  That’s the next thing on my list, right behind getting Test lined up and right in front of getting Dev lined up.

The component versions are finishing up in test right now – just a few minor issues to polish, and they should be ready for codesigning and release.  If all goes well, they should be on their way to the web release team by the end of this week, which means early next week for a real release, which will actually be a week quicker than the last set.  Once Test is lined up in WinSE to do this testing along side the other updates, we should be able to get the sign-off, code-signing, and release done at the same time as the desktop versions.  So while this month seems to be a step backward, things are looking good to have releases done and to you quicker each cycle.  As I mentioned before, the goal is to have Embedded updates available the same day as the desktop updates - we hope to have approached that goal by the end of this year, and be making steady progress towards it each cycle.

Now, in Other News:

I’ve had two comments from people on my Linux story from a few weeks back, trying to explain the vagaries of releasing GPL source code.  I’ve read the GPL, and to my understanding (section 3a and 3b), you either have to make the source available or tell people how they can get it, and not charge more than copying and media fees for it (i.e. you can’t give away the EXE but charge beau-coup bucks for the source).  Compare that with proprietary software (such as Microsoft makes), where the source code itself is IP (intellectual property), owned by the company or individual and protected by copyright, patent, and license law.  If you write proprietary software, you can charge whatever you want – if you write GPL software, you can’t really charge for the binaries nor the source other than some recovery costs, although it does open the market for add-on support and services (look at Redhat for an example, who make their money as a service-based business, since they can’t charge for the software directly [GPL Section 1]).  However, Microsoft and other proprietary software vendors do both – charge for the software, and charge for extended support.  It seems to me that proprietary software makes better economic sense.

I know I’ve cleared up nothing, and have probably opened myself up to more comments and religious arguments, but at least people are reading the blog.

MS Security Bulletins for April

There are scheduled security bulletins today for XP Pro – we’re already working on the Embedded versions, and the desktop version should be on the OEM Secure Site by the end of the week, next Monday at the latest.

To keep up to date, you can add the Microsoft Security Bulletin RSS feed to your favorite RSS reader (I use Serence KlipFolio) to get updates on what’s current, and keep a handy list of what was released in the past.

All this at no extra charge, like more ice water at a restaurant or watered down drinks at a Las Vegas blackjack table…

Unprotected PCs Fall To Hacker Bots In Just Four Minutes

You know, I thought I had blogged this back in November, but I can’t find it.  In any case, here’s the story, trying to find the original AvantGarde report.  There’s scary news (Windows XP SP1 machines on the Internet were owned – not hacked, probed, tested, but owned – on average in four minutes) and good news (Windows XP SP2 with the Windows Firewall on by default kept the machine from being compromised at all) and some duh news (no firewall in the world can save you from a weak or non-existant password).  The main points here:

• If you’re not running the Windows Firewall on SP2, you should be.
• If you’re not running any firewall, you should be.
• Set strong passwords on all your accounts (combination of lower-case alphas, UPPER-CASE ALPHAS, numbers, and symbols, at least six characters long)

TechWeb | News | Unprotected PCs Fall To Hacker Bots In Just Four Minutes | Nov. 30, 2004

A letter from a reader

Well, I guess I better start updating this a bit more – there are actually people reading it that I didn’t approach with the request, “PLEASE READ MY BLOG!”  Not that I’m that desparate for a readership, but who knows?  Should I decide to turn the corner from Helpful Embedded Guy to Evil Genius, a solid readership makes for a ready source of Evil Henchmen recruits… :-)

Anyway, on to the letter – Sana in Pakistan found my e-mail on the blog and is asking about Remote Boot.  His problem description (minorly editted):

I deployed (the base image) to target pc's hard-drive and ran it until I got Machine-resealed message. Further, I prepared a .sdi file from it. Using windows 2003 server, I configured dhcp & remote boot dervice. I gave Client's MAC address, boot program and boot image name in remote boot manager.

.sdi file size is 180 MB.
RAM: 320MB
Processor: 385MHz

The ramdisk image started loading and it completed. Next, the light blue screen, that showed that it's an XPE image of evaluation copy and it will expire in 120 days, was displayed.

Further, it moved to the page that we get when xp starts, like welcome page. Then it got stucked there though i waited for 30 mins. but it did'nt log on.

OK, so my take on this is that 320Mb is nowhere near anough memory to host a 180Mb RAM boot image plus have memory enough to run.  For any remote boot application, the bare minimum I think acceptable is twice the size of the SDI, plus a little extra (note that this is my opinion, not a statement of supported configurations).  In this case, the 180Mb RAM image leaves only 140Mb to load the system plus everything else.  Remember, when you boot the machine on HD, you’ve got 320Mb of memory to load stuff into (like FBA, services, drivers, etc).  Now you’ve cut down the memory by more than half – I’d expect some teething pains.

However, I realize that the runtime should have done something within 30 minutes, albeit slowly (assuming you have a shell defined properly – I’m skipping over some of the more obvious troubleshooting here, assuming the runtime boots on the PC properly).  My first step would be to shut the machine down, reboot into a safe build, and check the event logs on the embedded system – something may be failing that’s necessary.  Second step would be to try to boot with a kernel debugger hooked up.

Of course, I’d also try stripping as much unnecessary HW/SW from the machine as possible – check out my MSDN article on small footprint to find out how.  Basically, start with as small a system as possible as a sanity test on remote boot, then add things to the runtime until you’ve got your whole device up and running.  By starting small, you can eliminate a bunch of things that might be causing a problem, and if things stop working after you add something, you can isolate your troubleshooting to what was just added.  The problem is that you can’t just strip down a 180Mb runtime – you’ll have to start over with a small runtime and add things to make it functionally complete.

Any comments from the rest of the readership (both of you) are welcome.