altavista.firewall97.txt

`Date: Thu, 25 Feb 1999 12:57:20 +0100  
From: Jochen Thomas Bauer <[email protected]>  
To: [email protected]  
Subject: AltaVista Firewall97  
  
Hello everyone,  
  
Before I begin I want to make one thing clear:  
I told AltaVista about this problem about 4 weeks ago. The next day I got  
a reply saying that my message had been forwarded to engineering. Since  
then nothing has happened, so I think it's time to send this to BUGTRAQ:  
  
  
Abstract:  
  
In their so called Knowledge Database, AltaVista Software states that  
Firewall97 for Digital Unix is not affected by the well known buffer  
overflow bug present in BIND versions prior to 4.9.7 since all DNS queries  
are proxied through the Firewall's DNS proxy (dnsd), that can either relay  
queries to name servers running on other hosts or to a name server running  
on the Firewall itself.  
  
See: http://support.altavista-software.com/kb/solutions/firewall/general/259-042398.asp  
  
If the name server is running on the firewall itself (which is an approved  
configuration described in the manual), then there is a very simple way to  
circumvent the dnsd and attack the named on the Firewall directly. So,  
everyone who relied on this assurance (given shortly after those BIND  
problems were discovered) and did therefore not replace the named binary on  
the firewall with a self compiled BIND-4.9.7 named had (and may still have)  
a major security hole on his/her firewall.  
  
This problem is worsened by the fact that installation of the firewall  
software will alter some system files and therefore the Digital Unix patch  
utility (dupatch) will, at least in some cases, refuse to install several  
operating system patches including those for BIND.  
  
  
The Detailed Story:  
  
To divide the DNS information available about the internal network into  
information that is to be given to the outside world and information  
that is meant for internal use only, the AltaVista Firewall97 uses a DNS  
proxy (dnsd) running on port 53 on the firewall that redirects queries  
appropriately: Queries from external hosts are redirected to a name server  
that holds information to be given to the outside world, while queries from  
internal hosts are redirected to a name server that holds information meant  
for internal use only. Each of those two name servers may be running on another  
host or on the firewall itself. If one chooses to run one of the two or both  
name servers on the firewall, then the named(s) will be configured to listen  
on port 8053 and/or port 8153 (Firewall97 + Service Pack 3). The secure_zone  
statement  
  
secure_zone IN TXT 127.0.0.1:H  
  
in the zone files is then used to ensure that only queries from localhost  
(coming from the dnsd) are answered.  
  
The problem is that the named(s) running on port 8053/8153 will take input  
>from any host, logging these (unauthorized) queries like  
  
named[22343]: Unauthorized request nowhere.example.org from [129.69.xxx.yyy].1945  
  
So, if we want to attack the named on the firewall directly, we simply have  
to aim at port 8053/8153 instead of aiming at port 53. As I had no exploit code  
for Digital Unix I took a tool to exploit the named buffer overflow on ix86  
machines from www.rootshell.com, changed the target port to 8053/8153 and  
launched it against the firewall (running BIND-4.9.3). This caused a  
segmentation fault with core dump of the named. It should be possible to get a  
root shell out of that named with the appropriate exploit code for Digital Unix  
4.0a and higher, where the stack is executable.  
  
Let's turn to the patching problems now: I installed Firewall97 on Digital Unix  
4.0b + patch kit DUV40BAS00005-19971009 shortly after those BIND problems had  
been discovered last year. The Aggregate Selective patch kit duv40bas00008-19980821  
released in August 1998 contained fixes for BIND. When I tried to apply this patch,  
the dupatch utility found that several system files had changed due to the  
installation of the firewall software and refused to install several patches to  
ensure that no altered system file got overwritten by a new one from the patch  
kit. Unfortunately, among the patches that were not installed was the patch for  
BIND. I don't know if there is a single patch kit (not an Aggregate Selective patch  
kit) for Digital Unix addressing only those BIND problems and if that one works.  
  
The fix for the problems described above is quite simple: Compile a BIND-4.9.7  
named for Digital Unix and replace the named on the firewall with that one.  
However, what cannot be fixed is the fact that a lot of people were convinced  
that their firewall is secure, while in reality everyone, who had this knowledge  
about DNS on Firewall97 and the ability to write exploit code for Digital Unix,  
was probably able to immediately root-compromise their firewall.  
  
--  
Jochen Bauer  
Institute for Theoretical Physics  
University of Stuttgart  
Germany  
  
PGP public key available from:  
http://www.theo2.physik.uni-stuttgart.de/jtb.html  
  
-----------------------------------------------------------------------------------  
  
Date: Sat, 27 Feb 1999 21:50:01 -0800  
From: Roger Baker <[email protected]>  
To: [email protected]  
Subject: Re: AltaVista Firewall97  
  
I was one of a few beta testers outside Digital for Firewall98. I  
pointed out a year ago this problem in the beta. Firewall98 was going  
to be released with named 4.9.6. I raised hell, and they shipped 4.9.7  
with Firewall98. This problem is not so much with Firewall97 as it is  
with named. CERT 97-5 addressed this. To fix this problem you have to:  
  
1) Apply SP3 to Firewall97 to fix dnsd which connects the internal and  
external named's together. There is a bug in pre-SP3 dnsd. As was  
pointed out you still have to upgrade named to 4.9.7.  
  
2) Better yet upgrade to Firewall98 which fixes this problem. Remember  
that older software is more likely to have bugs. Firewall98 is more  
stable than Firewall97. The UNIX version of the Firewall97 was having  
problems with DNS. Firewall97 on DU brought secure DNS into the  
product. This was quite a step. There is no comparison between  
Firewall97 and Firewall98 on NT. Run, don't walk to Firewall98 if you  
use NT.  
  
3) The best solution is to upgrade named to 8.1.2. This breaks the  
installation scripts, but they were not good for DNS anyhow. The  
scripts do a poor job of setting up the MX records. I point out 8.1.2  
during the beta, and they said that they would try to put it in the next  
major release. No promises though. The people in product support  
recommend 8.1.2. There is no fancy GUI for this; just UNIX.  
  
This illustrates a major bug of mine. Security is not a product, but  
the person managing the product. A good product, and IMHO AltaVista  
firewall is one of the best, poorly installed will not work right.  
Security products are for the seasoned professional. For AltaVista (or  
Sun or Cisco) to make changes to their product requires that they spend  
a few miilion dollars on regression testing. A knowledgable manager can  
make the changes now.  
  
BTW, I know some of the folks in Engineering, and they are very good.  
Sometimes their hands are tied because whatever they say can legally  
bind the company. The Chief Engineer, Jeff Needle, follows the security  
products well. You are not going to get much support if you do not have  
the latest version with the latest patches.  
  
DO NOT USE the standard DU patches. One of them, I don't remember which  
one, breaks the firewall. The release notes tell you this. I you need  
help contact me off line, and I will be glad to help you. I know the  
AltaVista security products very well, and the people in Engineering  
know me. I am an independent consultant that often uses AltaVista  
products. The next major release of DU will probably include the  
firewall drivers as part operating system. YMMV  
  
Roger Baker  
[email protected]  
  
`