Date: 	Tue, 9 Jun 1998 00:03:44 -0400
Reply-To: Bugtraq List 
Sender: Bugtraq List 
From: Automatic digest processor 
Subject:  BUGTRAQ Digest - 5 Jun 1998 to 8 Jun 1998
To: Recipients of BUGTRAQ digests 
Message-Id: <19980609040542Z96077-9611+20@brimstone.netspace.org>

There are 8 messages totalling 375 lines in this issue.

Topics of the day:

  1. Security flaw in Accelerated-X 4.1
  2. FreeBSD Security Advisory: FreeBSD-SA-98:05.nfs
  3. PTE bug.. more..
  4. CISCO PIX Vulnerability
  5. ccasserole.c
  6. backdoor trojan in ICKill
  7. The Freefire Bulletin  #2 (1998-06-05)
  8. Administrivia

----------------------------------------------------------------------

Date:    Mon, 8 Jun 1998 17:31:36 +0300
From:    Stefan Laudat 
Subject: Security flaw in Accelerated-X 4.1

        Hello,

I don't know if this was posted before, please accept my appologies if so.
  Seems like the guys at XiG forgot the meaning of /tmp security ...
  The main problem is that the Install program of the AcceleratedX package
logs all in a file named /tmp/Install.log. So, every user knowing that
Mr ReWT is going to install this X server on his box can overwrite any
file on the system.
  The procedure is very simple: ln -s /etc/shadow /tmp/Install.log
  Oh, some of you may tell me : "What if AcceleratedX is already
installed?". There is also an Uninstall.log =->
  I think the /tmp/Xaccel.ini is also the temporary file for new
configurations, so wait for the root to change something and KAB00M! :))
  I am too lazy to cc this to the guys at XiG so please do it if you want.


---

Stefan Laudat aka Ninja
pager: 2233789 / 4105
ninja@protv.ro
IRC = Ninja || SSL || Kayden
http://www.cpc.pub.ro/~ssl
--------------------------------
"Use."

------------------------------

Date:    Fri, 5 Jun 1998 16:03:50 +1000
From:    matthew green 
Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-98:05.nfs

   Topic:          system crash with NFS


FYI:  this problem was fixed in NetBSD before 1.2.

------------------------------

Date:    Sun, 7 Jun 1998 00:25:27 -0700
From:    pedward@WEBCOM.COM
Subject: Re: PTE bug.. more..

Alex, (I'm cc'ing this to bugtraq to further educate people, and set the
comment I first made, right)

 I have located the positive source of the bug and am working on a patch.
The setrlimit will not work to prevent this.  You can only limit the number
of processes a person can launch, to limit the havoc they can cause.

The bug stems from the way Linux manages PGD, PMD, and PTE structures.  At
this time, Linux only deallocates PTEs when it frees page ranges.  PMD and
PGD structures are not checked for use when entries are freed from them.

I am working on a patch against 2.1 series kernels, which will be backported
to the 2.0 series.

So, to summarize:  It is a bug in that PMD and PGD structures are not
deallocated when they have dropped to 0 usage; no usage count can be
easily added to these because they are not "structures" in the normal
sense.  I have an algorithm that works for a small percentage of cases,
I'm working on the rest, and I should have a working patch soon (I hope :).

--Perry

>
> Good day!
> I've tried to use ulimit (setrlimit) as you suggest but really nothing of
> what you've said worked to me.
> If for example two or more users launch  ptebug  on my Linux system
> there is no way to block them, and they for sure will hang the computer
> after a while.
> I tried to limit everything ( number of process, virtual memory size, cpu
> limit ) but nothing avoid my system to crash.
> So I think that Sed (p6mip300@infop6.cicrp.jussieu.fr) has discovered a
> really serious bug and at the moment I can't see any fix for it
> ( of course I can deny the use of shell to the users but is not what I
> want )
>
> bye
>
> --
> Alex   |  mailto:hawk[at]ascu.unian.it |  http://www.ascu.unian.it/~hawk
> SySadm |  [ascu|studenti|www].unian.it |  phone/fax       +39-71-2204491
>
> [To err is human, to moo bovine.]
>
>


--
Perry Harrington        System Software Engineer    zelur xuniL  ()
http://www.webcom.com  perry.harrington@webcom.com  Think Blue.  /\

------------------------------

Date:    Fri, 5 Jun 1998 10:36:53 +0100
From:    Damir Rajnovic 
Subject: Re: CISCO PIX Vulnerability

Hi there,

At 10:19 -0700 4/6/98, Mat Butler wrote:
>On Thu, 4 Jun 1998, Damir Rajnovic wrote:
>
>> Hi there,
>>
>> At 19:25 -0700 3/6/98, David Wagner wrote:
>> >Either the sci.crypt folks were confused, or I am.  With only 48
>> >unknown bits in the DES key, you can break the encryption 2^8 = 256
>> >times faster than you can break DES.  This is a serious weakness.
>>
>> Probably I was unclear. What I want to say is that it does not matter
>> what bits inside key are known. It is the same if you know that first
>> 8 bits are 0 or middle or end bits. In all cases you must put the same
>> effort to break encryption. In that sense there is no 'additional gain'
>> knowing WHAT bits are fixed it does matter only that some are fixed.
>
>If you know the bits in the key that are fixed, you create a program to
>generate all possible combinations with those bits fixed.  (If nothing
>else, you create a list of every possible combination of the number of
>bits that aren't fixed, then insert the bits that are fixed before using
>the strings as keys.)
>
>It -does- matter if you know what bits are fixed.  We're talking the -key-
>here.  Not the output of the encryption.

Yes, but what I was trying to say is that if you know that first 8 bits
are fixed you can break encryption in X time units, so it will take again
X time units to break it if last 8 bits are fixed or any other 8 bits.
It will always take X time units no matter what 8 bits are known. There
is no, allegedly, 8 'preferred' bits that will allow you to break it in
less than X time units.

Cheers,

Gaus

---------------------------------------------------------------
EuroCERT                                tel: (+44 1235) 822 382
c/o UKERNA                              fax: (+44 1235) 822 398
Atlas Centre
Chilton, Didcot
Oxfordshire OX11 0QS, UK

------------------------------

Date:    Fri, 5 Jun 1998 15:04:55 PDT
From:    john smar 
Subject: ccasserole.c

I hope this hasn't been discussed already but..
i searched the bugtraq archives and didn't find anything so if its known
please
ignore this post but please respond to me in email. My work has been
under attack lately by something
called "chicken casserole", it constantly crashes all of our winnt/win95
and linux machines.
i long ago applied all of the hotfixes and upgraded all of our linux
machines to redhat 5.1
so they're running the newest kernel (0.34). nothing appears in any of
the log files, the machine just spontaniously reboots. A bunch of
kids from #hackphreak on the undernet keep bragging that they're doing
it and using a DoS exploits called "chicken casserole" and keep dumping
me parts of a program called "ccasserole.c" written by drhoney and
someone named nub. I asked in efnet #linux
and they told me no security vulnerabilitys exist that are not on cert
or bugtraq, so that i should look here, but i dont see anything. If
anyone
knows anything about chicken casserole please respond to me or to the
list
so i can keep these kids from constantly crashing my machines.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------------------------------

Date:    Sun, 7 Jun 1998 19:44:28 -0400
From:    Bachrach 
Subject: backdoor trojan in ICKill

    First off, I'm not 100% sure if this is the apropriate forum for this
since it's not really a weakness, but rather a programmer who is putting
backdoors
into some programs. Then again technically that's an exploits... Oh I
don't know. If this is the wrong place then I apologize profusely for the
waste of bandwidth and plead ignorance, but here goes:
    Well, chances are none of you guys have ever used this program, or even
heard of it, but there are alot (35,000) of people who have. I originally
downloaded it becasue I've been researching a lot of the weaknesses in the
ICQ protocol, (which has become easier as time has gone on. :)) Anyway,
after
you run it, (ICKill), it creates a file in the directory called 1.exe that
acts as a
fake explorer. 1.exe accesses your regedit database, and copies itself to
windows/system. It changes the regedit so that the fake one will run on
startup. It acts mostly the same as the normal explorer with one very
crucial execption. It contacts a host (I still can't figure out which one),
and executes the commands that are embedded within a text file on the
computer. Anyone see it yet? Backdoor city. I contacted the author (who left
his e-mail address in the readme), and he's the one who explained th
backdoor thing. He also told me a few other things that made me write up to
this group.
    He said that he had gotten almost 35,000 different people's systems
calling up his computer at one point; essentuially he has backdoors to
35,000 systems accross the globe. When I asked him why he would go through
all the trouble to do this he gave me two reasons:
1. IF (and he emphasized the if) he was a hacker he could use a couple of
other people's computers as hops when hacking into a system. Kind of nasty
for the sysadmin trying to trace a breaking huh?
2. To quote him "And the backdoors can auto-uptade themselves.. so Imagine I
can code a virus like backdoor... Whoaaa! This will be like THAT internet
worm.."
3. He also said "Imagine also.. 35,000 backdoored (yeah, I reached this
number)
connections pinging or SYN flooding some server.."

Well if anyone out there is using or has ever used ICKill then get rid of
it. I have actually set up a page on this to both inform people and explain
how to get rid of all traces of the program that I currently am able to at
http://members.tripod.com/~hakz/ICQ/index.html That site also has all of the
letters I wrote to him and he wrote to me if you want to see the entire
things. It's also got some other info I couldn't fit into this message,
including all of the mistakes the author made (guess he needed better beta
testing). My
last question is this: if one person has backdoors into thousands of
computer systems, doesn't that pose some sort of risk to the interent
community as a whole? There's one person who's been saying that I should
notify the FBI about this. As you can see  decided to start here first.

------------------------------

Date:    Fri, 5 Jun 1998 21:43:07 +0200
From:    Bernd Eckenfels 
Subject: The Freefire Bulletin  #2 (1998-06-05)

  The Freefire Bulletin #2 (1998-06-05) Monthly Newsletter


The Freefire Project tries to help Developers in building Firewall and
IT-Security Solutions based on Free Tools. You can find additional
information about the Project at the Homepage

     


0  Executive Info (Ec)
---------------------
1 Changes to the Web Pages (Ec)
  A new outfit and new content on the Freefire Web Pages

2 The DBD::pNET Perl Database Proxy (JW)
  is a proxy server for Perl DBI Databases with access control

3 FCT - Firewall Configuration Tool (JHF)
  generates executable scripts to setup a screening router

4 OpenBSD - A free and secure OS (Ec)
  OpenBSD emphasis on correctness, security and cryptography

5 Call for Authors
  If you want to participate in this bulletin, just drop me a note


1  Changes to the Web Pages (Ec)
--------------------------------
The Web Pages of the Freefire Project has changes a bit. Now all the Pages
are available in english (only the main-page is available in german, too).
The lists of resources and tools will be stored in a database, since
maintaining and checking the links tends to be hard work. Search and Rating
will be added.
You can find the pages at: 
(sorry about the typo in some of the last bulletins)


2  The DBD::pNET Perl Database Proxy (JW)
-----------------------------------------
is a proxy server for Perl based applications that want to access
a database engine behind a firewall or an engine without network
support. On the client side the module acts as a usual Perl DBI
driver, on the server side it uses the same DBI for accessing the
engine.

The driver offers a host and user based authorization scheme and
strong query restrictions: You can define a set of queries and
restrict the outside user (typically a WWW server) to those. The
package is available from any CPAN mirror, for example




3  FCT - Firewall Configuration Tool (JHF)
-----------------------------------------
generates executable scripts to setup a firewall for nearly all possible
configurations (single host, routing host, screened subnet, ...).
It actually supports the syntax for ipfwadm, ipchains and IPFilter. It offers
a HTML-CGI interface for configuration in any Browser. Also, it can fully be
administrered in a shell.




4  OpenBSD - A free and secure OS (Ec)
--------------------------------------
OpenBSD 2.3 is about to ship. It is one of the free BSD operating systems.
The OpenBSD Project is very successfull in keeping an eye on security. Quite
a few Bugs in OpenBSDs version of programs have been fixed before they
got announced in public.

>From IPFilter, securelevel, kerberos, MD5 passwords to tcpd and modified
(secured) versions of standard daemons (Bind) you get an operating sys-
tem which is constantly audited since 1996.




5  Call for Authors (Ec)
------------------------
Since this Bulletin is trying to be a monthly resource of good information
the Project is always seeking for authors. Please drop me a mail if you
want to write about something dealing with IT Security and free information
or solutions.


Authors of the current issue
----------------------------
  Ec  - Bernd 'eckes' Eckenfels    
  JW  - Jochen Wiedmann            
  JHF - Jens Hellmerichs-Friedrich 

(c) Copyright 1998 Bernd Eckenfels and others
Bernd Eckenfels , GERMANY

------------------------------

Date:    Mon, 8 Jun 1998 11:27:16 -0500
From:    Aleph One 
Subject: Administrivia

My mail spool crashed over the week end. If you submitted a post over the
last couple of days and haven't seen it please repost. I apologize for the
inconvenience.

I'll take this time to remind you that you can read BugTraq in a digest
form by sending a message to LISTSERV@NETSPACE.ORG with a body message of

  SET BUGTRAQ DIGEST

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01

------------------------------

End of BUGTRAQ Digest - 5 Jun 1998 to 8 Jun 1998
************************************************