From owner-freebsd-security Mon Jul 23 8:35: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from internethelp.ru (wh.internethelp.ru [212.113.112.145]) by hub.freebsd.org (Postfix) with ESMTP id 9517E37B401 for ; Mon, 23 Jul 2001 08:34:51 -0700 (PDT) (envelope-from nkritsky@internethelp.ru) Received: from IBMKA (ibmka.internethelp.ru. [192.168.0.6]) by internethelp.ru (8.9.3/8.9.3) with ESMTP id TAA89914; Mon, 23 Jul 2001 19:34:39 +0400 (MSD) Date: Mon, 23 Jul 2001 19:34:44 +0400 From: "Nickolay A.Kritsky" X-Mailer: The Bat! (v1.49) Personal Reply-To: "Nickolay A.Kritsky" Organization: IHelp X-Priority: 3 (Normal) Message-ID: <47174164064.20010723193444@internethelp.ru> To: "Jeroen Massar" Cc: freebsd-security@FreeBSD.ORG Subject: Re[3]: bin/22595: telnetd tricked into using arbitrary peer ip In-reply-To: <000f01c11379$72391a40$420d640a@HELL> References: <000f01c11379$72391a40$420d640a@HELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Jeroen, Monday, July 23, 2001, 5:14:40 PM, you wrote: JM> Matt Dillon wrote: >> All very nice, guys, but not realistic. Only FreeBSD uses an API. >> Third party programs access the structure directly for the most >> part so adding new fields to the structure will just cause more >> garbage to be written to the file (many third party programs >> don't bother to bzero the structure before writing it out). We >> aren't going to add a separate hostname[] array... we just got >> through ripping out the hostname crap, because there was never >> enough room in the field to actually store the FQDN, and many >> programs don't bother to verify the forward against the >> reverse anyway so the data would be suspect. And short >> of making a 200+ character array to hold it, which would be masive >> bloat, there is no way to fit it in the structure. If >> you want to store >> host names for posterity you will have to log-process the file and >> store the results somewhere else. Every program under >> the sun assumes >> utmp is a fixed-length structure. >> >> Pretty much our only option is to extend the size of >> existing fields >> and take the 'oh hell the structure size changed' hit. JM> So... Because they didn't account for this 40 years ago we're stuck with JM> it?? JM> Another proposal, because I know what you mean with the 'old programs' JM> problem which should have been fixed a long time ago with an API :) JM> Quote from my other mail: JM> 8<--- JM> One thing that should be considered to be done if an API is created... : JM> make a backport to previous versions of FreeBSD and actually JM> *BSD/Linux/* :) JM> This also encourages program writers/maintainers to adopt it quicker, as JM> it's less hassle for them and they don't have to make the JM> "pre-FreeBSD-5" case or something... JM> And the best thing of an API (if done right :): seperation of the back JM> and the frontend... which makes changes like this even easier... ---->>8 JM> But now... Make that API log into a different way and place... JM> We will get two wtmp/utmp files then... But then we can let the 'old' JM> 3rd party programs log to the 'old' utmp/wtmp facility. JM> Whenever a 'new' program using the API queries the listing function of JM> the API then the API will simply also check the 'old' facility... Et JM> presto ... We have a solution :) JM> The new solution could log to a database, file whatever you'd do with JM> it.... Just make sure that it fits into an API... :) looks quite reasonable to me - I considered it is the common way of such problems solving. ;------------------------------------------- ; NKritsky ; SysAdmin InternetHelp.Ru ; http://www.internethelp.ru ; mailto:nkritsky@internethelp.ru JM> That's also one of the reasons I am kinda glad that intel simply made JM> IA-64 not IA-32 compliant..... Away with the old stuff and backward JM> compatibility you got emu's (or API's who know the old stuff :) for JM> that... And Windows is going the same way too... NT != DOS ... Luckily JM> :) JM> Greets, JM> Jeroen JM> To Unsubscribe: send mail to majordomo@FreeBSD.org JM> with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message