July 2002 - openSUSE Security - openSUSE Mailing Lists

Bruno Leonhardt ist z.Zt. nicht im Büro ...
by BLeonhardt＠analytek.de 04 Jul '02

04 Jul '02

Ich werde ab 03.07.2002 nicht im Büro sein. Ich kehre zurück am 07.07.2002. Zur Zeit bin ich leider nicht im Haus, werde aber Ihre Nachricht so schnell wie möglich beantworten.

2 1

FW: Packet reconstructioni
by Reckhard, Tobias 04 Jul '02

04 Jul '02

Here's another interesting post (at least it was to me). Tobias > -----Original Message----- > From: Pete Ehlke [mailto:lists-djbdns@rfc822.net] > Sent: Wednesday, July 03, 2002 17:02 > To: dns(a)list.cr.yp.to > Subject: Re: Packet reconstructioni > > > On Wed, Jul 03, 2002 at 01:30:58PM +0200, Laurent G. Bercot wrote: > > > > > I'm wondering this topic isn't discussed more in-depth on > this list. > > > > Why should it be ? it's off-topic. > > This list is about BIND replacements for Unix ; the > problem lies within > > the BIND DNS client library. End of matter. > > > Erm. Well, no. It's also in BSD-derived libc implementations > going back > for *years*. It may take commercial vendors who use those > implementations some time to issue fixes. There are no doubt legacy > systems running that code whose vendors have gone out of > business. These > are real concerns in the real world, where 'get rid of those systems' > may not be an option due to management, human resource, technical, or > budgetary considerations, or may take months or even years to work > through the bureaucratic approval process. > > In that environment, responsible administrators take precautions to > protect systems that can't be immediately fixed. Right now, the only > option for doing that seems to be BIND 9. If this list is genuinely > "about BIND replacements for Unix", then discussing how to manage that > task using things other than BIND 9 is squarely on topic. > > -P. >

1 0

BIND resolver libraries vulnerable, was RE: Packet reconstruction i
by Reckhard, Tobias 04 Jul '02

04 Jul '02

Hi list I thought this post from the DNS mailing list might be interesting. Tobias > -----Original Message----- > From: Mrs. Brisby [mailto:mrs.brisby@nimh.org] > Sent: Wednesday, July 03, 2002 15:28 > To: dns(a)list.cr.yp.to > Subject: Re: Packet reconstructioni > > > On Wed, 2002-07-03 at 08:29, Lars Uffmann wrote: > > Laurent G. Bercot wrote: > > >>I'm wondering this topic isn't discussed more in-depth on > this list. > > > > > > > > > Why should it be ? it's off-topic. > > > This list is about BIND replacements for Unix ; the > problem lies within > > > the BIND DNS client library. End of matter. > > > > Sure. But CERT *recommends* usage of bind9 as a solution to > the buggy > > resolver library vulnerability. Earlier in this thread there was a > > dispute wether a caching nameserver (ie. dnscache) can > protect clients > > at all. I would like to know wether this is true or not. I > assume there > > are many people having the necessary expertise to answer > this question > > on this list, so it's not completely off-topic, IHMO. > > So CERT is wrong. whoopie. If CERT recommends you jump off a bridge, > then I won't cry if you actually do it... Irregardless of the pressure > from your "security staff" > > CERT recommends that you ignore the RFC's pertaining to DNS; > i've always > suspected the ISC corrupts CERT... but at least CERT can > pretend they're > doing "the right thing" by still giving the right answer: > > <<Upgrade to a corrected version of the DNS resolver libraries>> > > a caching nameserver should _not_ attempt to decode the underlying > responses (rrdata) of the answer section for a request it didn't > originate. IF IT DID, dnscache would have to be updated [or have a > rulefile] for each RR that __could__ be sent. > > This is impossible to do without breaking RFC 1123, 1035 and > 1034 (type > extensibility: dan has a good article about this at > http://cr.yp.to/djbdns/newtypes.html ) > > > if you simply need time and have to upgrade hundreds of > machines, simply > cut off users from talking DNS to the outside world (yes: kill > dnscache). > > Set up tinydns for your intranet so they can use "mail" and > "proxy" and > all that good stuff, and only permit them to use http proxies > (the HTTP > protocol puts the name of the host in the query when doing > "HTTP PROXY") > > And congrats are in order: You've successfully avoided > replacing the DNS > resolver on all the broken machines by cutting off their privleges. As > they become compliant and decide, okay, we'll do it the right way, add > them to your dnscache $ROOT/ip/ > >

1 0

RE: [suse-security] ipchains - paketfilter
by Reckhard, Tobias 04 Jul '02

04 Jul '02

> network. Is it correct, that squid and rinetd are > using the input and output chains and not the forward > chain. I'm not entirely sure about rinetd as I haven't used it myself, but you are correct concerning Squid. I presume the same applies to rinetd. The reason is simple: Squid is a proxy, which breaks up the communication between client and server into two individual conversations. The proxy is a server to the client (conversation #1) and a client to the server (conversation #2). > And does it make sense in your opinion to > define new chains for that? Your call to make. It can improve or degrade the readability and performance of chains to introduce user-defined chains. It depends on the complexity of the rulebase. Tobias

1 0

[suse-security] SSL logs 'ok', but no open port 443
by Ulrich Klaus (listaccount) 03 Jul '02

03 Jul '02

Dear colleagues, i hardly tried to enable SSL with apache on my SuSE 7.0 box using the [latest fixes of the] following packages: apache-1.3.19-115 mod_ssl-2.8.2-33 mod_php4-4.0.4pl1-132 (self-compiled from the spm) After creating the key, csr and crt and modifying the httpd.conf accordingly, apache restarts quite well, writing the ssl_engine_log as completely listed below (log-level debug). So, everything seems fine, furthermore because no other logfile contains suspicious entries. But -- there is no listening port 443 at all. Could anybody pleas give me a hint how to see the cause? Thanks a lot in advance Uli /var/log/httpd/ssl_engine_log: [03/Jul/2002 23:20:45 02246] [info] Server: Apache/1.3.19, Interface: mod_ssl/2.8.2, Library: OpenSSL/0.9.5a [03/Jul/2002 23:20:45 02246] [info] Init: 1st startup round (still not detached) [03/Jul/2002 23:20:45 02246] [info] Init: Initializing OpenSSL library [03/Jul/2002 23:20:45 02246] [info] Init: Loading certificate & private key of SSL-aware server my.name.de:443 [03/Jul/2002 23:20:45 02246] [trace] Init: (my.name.de:443) unencrypted RSA private key - pass phrase not required [03/Jul/2002 23:20:45 02246] [info] Init: Seeding PRNG with 136 bytes of entropy [03/Jul/2002 23:20:45 02246] [info] Init: Generating temporary RSA private keys (512/1024 bits) [03/Jul/2002 23:20:45 02246] [info] Init: Configuring temporary DH parameters (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: 2nd startup round (already detached) [03/Jul/2002 23:20:46 02247] [info] Init: Reinitializing OpenSSL library [03/Jul/2002 23:20:46 02247] [trace] Inter-Process Session Cache (DBM) Expiry: old: 0, new: 0, removed: 0 [03/Jul/2002 23:20:46 02247] [info] Init: Seeding PRNG with 136 bytes of entropy [03/Jul/2002 23:20:46 02247] [info] Init: Configuring temporary RSA private keys (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: Configuring temporary DH parameters (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: Initializing (virtual) servers for SSL [03/Jul/2002 23:20:46 02247] [info] Init: Configuring server my.name.de:443 for SSL protocol [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Creating new SSL context (protocols: SSLv2, SSLv3, TLSv1) [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring permitted SSL ciphers [ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL] [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring RSA server certificate [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring RSA server private key

2 1

skyrider@poke53280.de
by Ulrich Klaus (listaccount) 03 Jul '02

03 Jul '02

Very very sorry - this subject was silly. Uli

1 0

skyrider@poke53280.de
by Ulrich Klaus (listaccount) 03 Jul '02

03 Jul '02

Dear colleagues, i hardly tried to enable SSL with apache on my SuSE 7.0 box using the [latest fixes of the] following packages: apache-1.3.19-115 mod_ssl-2.8.2-33 mod_php4-4.0.4pl1-132 (self-compiled from the spm) After creating the key, csr and crt and modifying the httpd.conf accordingly, apache restarts quite well, writing the ssl_engine_log as completely listed below (log-level debug). So, everything seems fine, furthermore because no other logfile contains suspicious entries. But -- there is no listening port 443 at all. Could anybody pleas give me a hint how to see the cause? Thanks a lot in advance! Uli /var/log/httpd/ssl_engine_log: [03/Jul/2002 23:20:45 02246] [info] Server: Apache/1.3.19, Interface: mod_ssl/2.8.2, Library: OpenSSL/0.9.5a [03/Jul/2002 23:20:45 02246] [info] Init: 1st startup round (still not detached) [03/Jul/2002 23:20:45 02246] [info] Init: Initializing OpenSSL library [03/Jul/2002 23:20:45 02246] [info] Init: Loading certificate & private key of SSL-aware server my.name.de:443 [03/Jul/2002 23:20:45 02246] [trace] Init: (my.name.de:443) unencrypted RSA private key - pass phrase not required [03/Jul/2002 23:20:45 02246] [info] Init: Seeding PRNG with 136 bytes of entropy [03/Jul/2002 23:20:45 02246] [info] Init: Generating temporary RSA private keys (512/1024 bits) [03/Jul/2002 23:20:45 02246] [info] Init: Configuring temporary DH parameters (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: 2nd startup round (already detached) [03/Jul/2002 23:20:46 02247] [info] Init: Reinitializing OpenSSL library [03/Jul/2002 23:20:46 02247] [trace] Inter-Process Session Cache (DBM) Expiry: old: 0, new: 0, removed: 0 [03/Jul/2002 23:20:46 02247] [info] Init: Seeding PRNG with 136 bytes of entropy [03/Jul/2002 23:20:46 02247] [info] Init: Configuring temporary RSA private keys (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: Configuring temporary DH parameters (512/1024 bits) [03/Jul/2002 23:20:46 02247] [info] Init: Initializing (virtual) servers for SSL [03/Jul/2002 23:20:46 02247] [info] Init: Configuring server my.name.de:443 for SSL protocol [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Creating new SSL context (protocols: SSLv2, SSLv3, TLSv1) [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring permitted SSL ciphers [ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL] [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring RSA server certificate [03/Jul/2002 23:20:46 02247] [trace] Init: (my.name.de:443) Configuring RSA server private key

1 0

RE: [suse-security] IPsec (FreeS/WAN) and SuSEfirewall2
by Andreas Marbet 03 Jul '02

03 Jul '02

> -----Original Message----- > From: Robert Klein [mailto:RoKlein@roklein.de] > Sent: Wednesday, July 03, 2002 9:56 PM > > > > On leftgateway's ipsec.conf change the rightnexthopvalue to the > > internal IP of rightgateway and vice versa. > > I don't think that's the way it's supposed to be... But I solved my problems exactly that way. If anybody has a better solution, please tell me. > > > To manage to fulfill #2 i also added the following tunnels in > > > ipsec.conf: > > > ----------------- > > > conn xpfwlsn-xpfwn > > > # Subnet to gateway > > > > > > conn xpfwl-xpfwnsn > > > # Gateway to subnet > > > > Is it really neccesary to add these connections as well? I think > > FreeS/WAN will be confused because it doesn't know how to > differ the > > incoming connection requests. Could you perhaps post the > log-entries > > when starting FreeS/WAN? > > Yes, it is neccesary, for the gateways to reach the opposite subnet. But the gw (with only one tunnel between the subnets) has its routing table that tells it how to route eg packets to the remote subnet (via ipsec-interface). The packet will arrive there and be passed over to ipsec that decrypts the packet and again passes it over to the internal interface. Isn't it correct that way? Of course gw to gw doesn't work via ipsec that way. > > > Jul 3 14:31:42 xpfwl kernel: SuSE-FW-DROP-DEFAULT IN=ipsec0 > > > OUT=eth1 SRC=194.194.194.200 DST=192.168.1.10 LEN=84 TOS=0x00 > > > > Why does it arrive on ipsec0, should be eth0. Taking the > wrong tunnel? > > No. All traffic between the two networks should go through > ipsec0. (Or else it wouldn't use frees/wan...) but not traffic from an IP not belonging to the specified subnets, eg official IPs in that case. IRC only IPs of the two subnets should arrive on ipsecX. Prost, Andreas

2 1

Re: [suse-security] Apache upgrade from SuSE ?
by Oliver Bleutgen 03 Jul '02

03 Jul '02

> Hi Oliver, >> the problem with the apache upgrade seems to be that the stock apache >> from SuSE 7.0 was 1.3.12 (IIRC, it was definately <1.3.19). > Yes, that's right. >> Then, on 28.April 2001, SuSe seems to have issued a apache 1.3.19 for >> suse linux 7.0, at least that is what I figure out from the fact that > Yes. >> http://www.suse.de/de/support/download/updates/70_i386.html >> >> contains links to mod_contrib.rpm, mod_perl.rpm and other modules >> for apache 1.3.19. > Strictly speaking those module updates should not have been necessary. I doubt that, from my own experiences. > The module API has not changed since back 1.3.12 days. However, there > are some other package interdependencies as well -- (if you ever typed > ldd /usr/lib/apache/libphp4.so you know what I mean...) so if for > example openldap has been updated meanwhile as well and the API used by > php has actually changed, you might end up updating a rebuilt php > package as well. I.e. a package like mod_php might have to rebuilt quite > often. Now the problem is not, for us, to track down these build > dependencies, but to cut them down by translating them into a set of > packages that need rebuilding/updating (on your system!) or not. It's > very complex, unfortunately. I know of the problems, and I think your strategy, as also used with the openssh issue, is the right one. >> Irritatingly, there's no link to an apache 1.3.19 upgrade from that >> time, maybe you people deleted that when the new apache came out. > Do you mean the symbolic link named apache.rpm? It always points to the > current rpm for convenience, so it has been changed since then. No, I mean a link and a note at http://www.suse.de/de/support/download/updates/70_i386.html As you see, there are said modules listed at 28.April 2001, but not apache itself. Before I upgraded, I grepped this page for other occurrencies of the word "apache" and found nothing else. So I concluded that apache hasn't been updated before. >> Now came the new upgrade, and only mod_ssl and apache itself were >> published. People like me upgraded, got no rpm dependency problems >> (yes, without using --nodeps), but apache segfaulted on every request. > As the same procedure has worked for many people, I assume that there is > something in your setup. A special set of modules or something else. Maybe the other people had done the previous update, I didn't, and at least two people on the mailing list didn't also and had seemingly the same problem. > Important: we assume that people have installed the previous security > updates of apache. I hope that this is a fair assumption? Not quite, as you see now. I don't know what the issue was on April, 28th 2001, and I don't find a security anouncement from SuSE concerning apache from that time. But I'm quite sure that _if_ it had been an issue for my servers, I had upgraded apache - but I hadn't. Look at the last openssh issue, I think it's reasonable _not_ to assume that everyone will update openssh - it's just not an issue for people with most configurations. If, in the future, SuSE updates any package which needs the new openssh (not very likely, I know) on 7.0, the same thing could happen again. >> It took me some time to figure out that my apache modules were the >> culprits, because I _had_ checked for a previous apache upgrade which >> I might have omitted for some reason - and, as I said, rpm didn't >> complain. > You had the modules from stock 7.0 installed (hope I got you right)? > They should actually work with the current apache, with the exception of > mod_ssl. Do you know which specific module failed? After I updated mod_contrib and mod_perl, the servers ran alright - before that, segfaults on every request. But the server started up ok. Another data point: even using the src.rpm didn't help. Ok, one thing, I had mod_gzip compiled for apache 1.3.12. But I had tried to get a working apache without that - it didn't work. To elaborate, I commented out everything in httpd.conf which is related to mod_gzip. It didn't work, but after updating the two modules, itd did, in the exact same configuration. > Sometimes, when we can't avoid to make version updates of packages > (and apache 1.3.12->1.3.19 is such a candidate) it can't be guaranteed > that the build procedure can actually be the same. > Two examples: > 1) Newer apache versions (>1.3.22 or so) use an external (system > installed) expat library in favor of the internal one, to avoid library > symbol name clashes when a module (say, mod_perl) loads the external > expat lib into the same namespace. > 2) With apache 1.3.23 or so and later the accept serialization method > has been made runtime configurable. The configuration style has changed. > Simply and boldly offering apache 1.3.26 updates for all distributions > would be prone to break a lot of things because of changes like that. It > would be hard to get it right again, so everything works still as > expected, the configuration files are still valid, and so on. It's absolutely no question for me that staying with the same version number and backporting security patches is the right thing to do under almost any circumstances. Esp. with apache, where there may be custom modules which depend on that very version. >> It would have been helpful if the advisory contained a hint about >> updating the apache modules, because the described update strategy >> _must_ fail on a stock 7.0. > As I understand it, we would need a special hint for users that have > never installed one of the previous apache updates before. > Wrt the texts of the module update packages, they say "update package > for apache 1.3.19". Which is what they ought to say. This is correct, but if it's true that one needs to have other, older updates to get a working server, it would be a great help to describe that in the advisory. What happend was: stock 7.0 -> apache+mod_ssl update from 18.Jun 2002 -> crash what I had to do was: stock 7.0 -> mod_contrib+mod_perl from 28.April 2001 + apache+mod_ssl from 18.Jun -> works IOW, the update from 18.Jun was dependend on the update from 28.April 2001, and that was neither mentioned in the advisory nor reflected in the rpm-dependencies. >> Mind you, I'm not complaining, just trying to give a hint where these >> problems might come from. > We are greatful for such help! And you are doing a great job, esp. with the last two big "incidents". cheers, oliver

3 4

IPsec (FreeS/WAN) and SuSEfirewall2
by Stefan Nilsen 03 Jul '02

03 Jul '02

Hi. I have been trying to setup a few tunnels between two private subnets over the internet. The GW computers should also act as masquerading firewalls for the users on the subnets. The GW computers is running SuSE 8.0. My goals is the following: #1. Allow the users on the subnets to reach each other #2. The GW computers should be able to reach the opposite subnet #3. The GW computers should be able to talk to each other. (Does not *have* to be IPsec, SSH is enough). I have managed to fullfill #1 together with #3, but not without troubles. I had to make minor changes in /etc/init.d/SuSEfirewall2_setup, adding ipsec to the row containing Required-Start: Then I went into yast2, runlevel editor and made a reset of the runlevels. I am sure this could also be done from the cmdline... The reason I did this was because ipsec has to be loaded before the firewall, otherwise it would not load the rules correctly for the ipsec0 interface. The following tunnel was set up in /etc/ipsec.conf on both GW's to get this tunnel to work: ---------------- conn xpfwlsn-xpfwnsn # Subnet to subnet # Left security gateway, subnet behind it, next hop toward right. left=193.193.193.200 leftsubnet=192.168.1.0/24 leftnexthop=193.193.193.193 # Right security gateway, subnet behind it, next hop toward left. right=194.194.194.200 rightsubnet=192.168.3.0/24 rightnexthop=194.194.194.194 # To authorize this connection, but not actually start it, at startup, # uncomment this. #auto=add auto=start ----------------- To manage to fulfill #2 i also added the following tunnels in ipsec.conf: ----------------- conn xpfwlsn-xpfwn # Subnet to gateway # Left security gateway, subnet behind it, next hop toward right. left=193.193.193.200 leftsubnet=192.168.1.0/24 leftnexthop=193.193.193.193 # Right security gateway, subnet behind it, next hop toward left. right=194.194.194.200 # rightsubnet=192.168.3.0/24 rightnexthop=194.194.194.194 # To authorize this connection, but not actually start it, at startup, # uncomment this. #auto=add auto=start conn xpfwl-xpfwnsn # Gateway to subnet # Left security gateway, subnet behind it, next hop toward right. left=193.193.193.200 # leftsubnet=192.168.1.0/24 leftnexthop=193.193.193.193 # Right security gateway, subnet behind it, next hop toward left. right=194.194.194.200 rightsubnet=192.168.3.0/24 rightnexthop=194.194.194.194 # To authorize this connection, but not actually start it, at startup, # uncomment this. #auto=add auto=start ----------------- ... but it does not work. I suspect SuSEfirewall2 to be the reason (or more correctly, my configuration of the firewall). My /etc/sysconfig/SuSEfirewall2 config (only diff's from /usr/share/doc/packages/SuSEfirewall2/SuSEfirewall2.conf): ----------------- FW_DEV_EXT="eth0 ipsec0" FW_DEV_INT="eth1" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="eth0" FW_MASQ_NETS="0/0" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_SERVICES="no" FW_SERVICES_EXT_TCP="ssh" FW_SERVICES_EXT_UDP="500" FW_SERVICES_EXT_IP="50" FW_FORWARD="192.168.1.0/24,192.168.3.0/24 192.168.3.0/24,192.168.1.0/24" FW_KERNEL_SECURITY="no" FW_STOP_KEEP_ROUTING_STATE="yes" ----------------- If I ping a computer on subnet 192.168.1.0/24 from the opposite network GW i get this in /var/log/messages on the recieving GW: Jul 3 14:31:42 xpfwl kernel: SuSE-FW-DROP-DEFAULT IN=ipsec0 OUT=eth1 SRC=194.194.194.200 DST=192.168.1.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=44295 SEQ=3584 Jul 3 14:31:43 xpfwl kernel: SuSE-FW-DROP-DEFAULT IN=ipsec0 OUT=eth1 SRC=194.194.194.200 DST=192.168.1.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=44295 SEQ=3840 How can I get SuSEfirewall2 to allow this traffic? And for #3: When I have enabled the tunnels conn xpfwlsn-xpfwn and xpfwl-xpfwnsn the traffic from GW1 to GW2 is silently dropped. Using snort (sniffer) I can see that the data is encapsulated on ipsec0 but no data is sent on eth0 ! The data between the subnets still flows correctly in the tunnel. I would be very happy for *any* info on this matter. It is driving me crazy... Stefan.

2 1