Unfortunately, this sort of behavior is also what caused many of the failures for 05-051 and necessitated the follow-on KB for restoring permissions to the %windir%\registration folder and contained .clb packages.
Remember; all MS code is tested in the context of OOB deployment and MS-published security guidelines. The minute you step out of those boxes, you're taking some not-so-insignificant risks upon yourself and your customers. Luckily, the recommendations made therein are limited to folders and registry entries specific to QBP, so they don't raise too many hackles, assuming you limit local & remote access to that machine for trusted users only. I'd hate to see your customer's financials get sold to the highest bidder for all those changes... Jim Harrison Security Platform Group (ISA SE) If We Can't Fix It - It Ain't Broke! -----Original Message----- From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [mailto:[EMAIL PROTECTED] Sent: Friday, November 11, 2005 11:24 AM To: matthew patton Cc: [email protected] Subject: Re: What server hardening are you doing these days? QuickBooks Community - Running QuickBooks 2005 as a Restricted User (Admin Rights FIX): http://www.quickbooksgroup.com/webx?14@@.eeb323b/9 We throw vendor documentation in the trash all the time and hack registries and hives. matthew patton wrote: > ok, seems I need to clarify since several people have responded with > their bookmark collection of tips, cheats, workarounds, papers, etc. > etc. etc. > > While not having looked at all of them, the point is none of them has > bothered to address the basic, out of the box faults of the windows > filesystem permissions, nor the culture of permissiveness that > permeates all things windows. It's one band-aid after another. > > LocalSystem isn't 'root'. It's similar in some aspects, but I can trash > an NT box by denying LocalSystem permissions to certain files. I can > lock out the Administrator likewise. The point is not that there aren't > a zillion different guides to living "more safely" with windows. The > point is that on a most rudimentary level, when you start with > LocalSystem having Full Control over the entire disk and there is NOT > ONE reason for it to be that way, you have a situation where security > wasn't thought thru. IIS has no business running as LocalSystem for > example. It should be fully capable of running as a 'normal' user with > maybe a couple of special privs attached. The concept and > implementation of 'sudo' has been around for what, more than 10 years? > > How many of you throw the vendor documentation in the trash and > actually make the product run as an unprivileged user? Say Oracle? or > ColdFusion, or WEbsphere, BEA, etc? Think about it. You have all these > operating system components, 3rd party "daemons", and who knows what > all running as the same user. And said user has full control > permissions to practically every file on the disk. So what that maybe > there are 30% fewer buffer overflows in the unholy number of millions > of lines of code. If the filesystem/registry permissions are such that > LocalSystem can't do jack, I don't care so much if there are glaring > problems. (not to imply I condone sloppy coding) > > I have yet to find a guide that actually spelled out the REAL > permissions needed for LocalSystem. It needs 'read' to pieces of the > %system% tree and 'write' to a couple of files but that's it. Mention > to Microsoft that you've wholesale mucked with their "anything goes" > permission set and they have a coronary and disavow any notion of > support. Why is that? Are they ignorant about what their own product > actually needs? Where is the security team that has gone thru and > redefined all permissions to what they should be and told the > programmers to go back and fix their code? > > The filesystem is the easy one. I don't have the interest or the time > to bother with the registry though in some respects that's probably > more important. > > ------------------------------------------------------------------------ --- > ------------------------------------------------------------------------ --- > > > -- Letting your vendors set your risk analysis these days? http://www.threatcode.com ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- ---------------------------------------------------------------------------
