From secprog-return-507-jm=jmason.org@securityfocus.com Wed Sep 18 11:50:54 2002 Return-Path: Delivered-To: yyyy@localhost.example.com Received: from localhost (jalapeno [127.0.0.1]) by jmason.org (Postfix) with ESMTP id 4472916F03 for ; Wed, 18 Sep 2002 11:50:53 +0100 (IST) Received: from jalapeno [127.0.0.1] by localhost with IMAP (fetchmail-5.9.0) for jm@localhost (single-drop); Wed, 18 Sep 2002 11:50:53 +0100 (IST) Received: from outgoing.securityfocus.com ([205.206.231.27]) by dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g8I4XsC12571 for ; Wed, 18 Sep 2002 05:33:54 +0100 Received: from unknown (unknown [205.206.231.19]) by outgoing.securityfocus.com (Postfix) with QMQP id 9727BA30C2; Tue, 17 Sep 2002 20:13:31 -0600 (MDT) Mailing-List: contact secprog-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list secprog@securityfocus.com Delivered-To: moderator for secprog@securityfocus.com Received: (qmail 11785 invoked from network); 17 Sep 2002 15:39:18 -0000 Date: Tue, 17 Sep 2002 14:51:23 +0200 (CEST) From: Allan Jensen To: Richard Bartlett Cc: secprog@securityfocus.com Subject: Re: The risks of client systems writing to server registry In-Reply-To: <20020905134739.1071.qmail@mail.securityfocus.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-104.3 required=7.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,KNOWN_MAILING_LIST, QUOTED_EMAIL_TEXT,USER_AGENT_PINE,USER_IN_WHITELIST version=2.50-cvs X-Spam-Level: On 5 Sep 2002, Richard Bartlett wrote: Richard, > I have a customer who is developing some printer driver code to allow > custom driver settings (n-up, booklet, duplex etc.) to be saved up to the > server to be retrieved by other users. The data is being written, by a > printer driver (using the logged on users authentication, to a registry > key) HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT > x86\Drivers\Version-3\{Driver Name}\{Custom Key}\Subkey). Let me get this straight; a registry key is loaded from the server onto the client workstations who can modify it, then write it back onto the server's own registry - which is not going to use it? > The question is, what are the security risks of allowing users to write > to this key? The data is string data, in the form of delimited numeric > values. This data is then retrieved by capable printer drivers and > interpreted. > > The risks as I see it are twofold; > (1) The risks of a compromise to the server using this registry key. I > think this is unlikeley as the server itself does not use this data, only > client PC's do. Unless someone knows a way to travel out of a hive up > the registry bypassing the permissions set using regedt32. What is the reason to write a registry key to a server if the server itself is not using it? I don't think you should worry too much about someone travelling out of the hive, but again, I'm curious as to how the driver actually modifies the keys on the server. > (2) The risks of a compromise to the client (far more likely). This > would probably be by a malformed or extremely long string in the key > value, which would presumably lead to either DOS or system compromise by > buffer overflow on the client system. And if the client writes the key back onto the server, yes, there's wide open for something nasty here. Two other things spring to mind; 1) If anyone can modify the key, how do you make sure that two users are not overwriting the same key, thereby causing undesirable effects. 2) If anyone have permissions to write to the key (and below), anyone can create thousands of extra keys under this key, thereby filling up the registry. The result of such a thing is obvious. If I got this all wrong, I'd be happy that you clarify a bit more and tell me where I might have misunderstood. Med venlig hilsen / Best regards, -Allan Jensen Si hoc signum legere potes, operis boni in rebus Latinus alacribus et fructuosis potiri potes!