Xref: utzoo comp.unix.wizards:13377 news.admin:4269 news.sysadmin:1924
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!eda!jim
From: jim@eda.com (Jim Budler)
Newsgroups: comp.unix.wizards,news.admin,news.sysadmin
Subject: Re: unshar business
Message-ID: <395@eda.com>
Date: 11 Dec 88 18:48:51 GMT
References: <232@logicon.arpa> <7876@well.UUCP>
Reply-To: jim@eda.com (Jim Budler)
Organization: EDA Systems,Inc. Santa Clara, CA
Lines: 45

In article <7876@well.UUCP> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes:
| Well, I have looked at Cathy's program, all 93 lines of it, and unless
| I'm reading it wrong she wasn't paying much attention either.  Consider
| the following somewhat twisted fragment where she gets the output filename
| from the shar file:
| 
| 	    strncpy(file2,&buffer[20],(strlen(&buffer[20]) - 1));
| 	    printf("opening file {%s}\n",file2);
| 	    if((fp2 = fopen(file2, "w")) ==  NULL) {
| 
| Do you see anything in there to prevent "../../../../etc/passwd"?  I sure
| don't.
| 

Oh!!! You unpack your maps as root! Gasp! <--- sarcasm 8^)

I unpack my maps as 'news'.

Currently the damage is limited to the news heirarchy, plus the news library.
I may modify the source to disallow any '/'.

| By the way, uns.c uses a fixed size buffer, only 256 characters long.
| I have right here in my home directory a shar file with a 288 character
| line.

It was I beieve, designed to unpack maps, not general shar files.

| 
| These are minor nits, easily fixable, but I thought someone ought to
| point them out before people start installing uns.c and thinking they
| are secure.

They are much more secure than previous unshars, commands being
disallowed entirely. You made the problems sound much worse than they
are. Lighten up.

| ---
| Jef


-- 
Jim Budler   address = uucp: ...!{decwrl,uunet}!eda!jim OR domain: jim@eda.com
#define disclaimer	"I do not speak for my employer"
#define truth       "I speak for myself"
#define result      "variable"