From owner-freebsd-audit Sat Aug 12 8:12:52 2000 Delivered-To: freebsd-audit@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ACE9037B6CB; Sat, 12 Aug 2000 08:12:46 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 12 Aug 2000 11:12:45 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Martin Cracauer Cc: Kris Kennaway , audit@FreeBSD.ORG Subject: Re: Fuzz testing In-Reply-To: <20000812144822.A3193@cons.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 12 Aug 2000, Martin Cracauer wrote: > > However, Martin Cracauer seems to think making it 8-bit clean is done > > by not escaping the control characters :-( I have no idea how you > > would believe that control characters are "okay" to leave unescaped > > "just because" they're used by a character set, and indeed that should > > be all the more reason to make sure they're properly escaped. > > This is FUD, . If I'm pissed off enough about the problem to make it seem like that, I'm glad. Call me what you like. > I said it is preferrable to change the whole stuff to 16 bits per char > (different space for chars and control things) over just escaping > chars in the same space. Never did I neglect the problem. Of course that's preferable, but can you tell me what deltas like this are doing: @@ -906,7 +908,13 @@ CHECKEND(); /* set c to PEOF if at end of here document */ for (;;) { /* until end of line or end of word */ CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */ - switch(syntax[c]) { + + if (c < 0 && c != PEOF) + synentry = CWORD; + else + synentry = syntax[c]; + + switch(synentry) { case CNL: /* '\n' */ if (syntax == BASESYNTAX) goto endword; /* exit outer loop */ How in the world is is "putting your finger in your ears" about control characters better than escaping them?? > 16-bits/different space is certainly more secure since you are robust > against coding errors in all the zillion place you would need to take > escaped chars into account. Just never have a control thing where you > would expect a char (in the lower 8 bits of the 16). What justification is there to remove the carefully coded control escapes that have been there before? > > This needs a hell of a lot of reversion to fix. Yes, I think this > > probably security implications :-( > > The complex sh rules make it almost impossible to make sh scripts > secure, no matter how good the implementation is. Anyone who > exectutes possibly unfriendly sh scripts under a to-be-protected > userid is just insane. I'm not talking about possibly unfriendly. I'm talking about your own. Am I to understand that none of the control sequence parsing code ever deals with user input? > Again, I certainly will make sh 8-bit clean unless someone pisses me > off too badly. So how is it more clean here: {"/home/green"}$ printf echo\ '\204'Hello. | sh Memory fault (core dumped) > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer http://www.cons.org/cracauer/ > BSD User Group Hamburg, Germany http://www.bsdhh.org/ > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message