July 2002 - openSUSE Security - openSUSE Mailing Lists

05 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Are any of you using the grsecurity kernel patch? I'm just trying to teach myself how to use it. It's pretty neat. YaST is doing somethign which it considers dangerous, because it kills it: Jul 5 01:01:04 ccs001 kernel: grsec: signal 11 sent to (y2base:13088) UID(0) EUID(0), parent (y2base:15754) UID(0) EUID(0) That happened while trying to install new packages Yet I can install rpms by hand with no trouble. Before I go plauge the relatively small group of grsecurity folks, are there any SuSE user's of grsec that can give me basic tips, like what to do to allow YaST to work? Thanks. - -- - ---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9JTMeQ5u80xXOLBcRAtRQAJ9ilVyGJ/s/b4rp++xHCCUqGbGEEQCeJWZn gvrbObD4M/OPWA32qcMS0UQ= =sNrY -----END PGP SIGNATURE-----

2 1

Firewall On CD & Routing.
by Tom Crowe 05 Jul '02

05 Jul '02

Hi, I have a quick question regarding firewalling using Firewall on CD and routing. The firewall on CD manual advises not to route packets, but to proxy wherever possible, and in the absence of a proxy for my particular application, I am looking to find out if what I want to do can be done without routing, and where the routing may need to be deployed. My opinion differs with the ISP, and I need a second opinion before I concede defeat or demand victory. The setup is that our office facility has a leased line terminating in a router, and provides internet connectivity to multiple clients from the one line. The router which the line terminates in is x.x.x.2 and every IP address we have traceroutes through that router. We have a block of 16 IP addresses from the block of 256 available, we have x.x.x.49..63 all in its own subnet with an appropriate subnet mask to keep the broadcasts local. The ISP installed some type of dumb gateway on 49 to allow our outgoing traffic reach the router on x.x.x.2 without being in the same subnet as that router, but all incoming traffic avoids the gateway on .49 All taceroutes for any of our 16 IP's route up to and including x.2 router. I propose to place a firewall with public interface on .50 and split the remaining IP addresses, x.51..63 into a disjoint network which I shall use as a DMZ. The dmz is intended to run http server, pop, smtp, and a special demo server and another server running VNC server. I propose to have the firewall route this traffice if it reaches the external interface for somthing in the DMZ. Outgoing traffic will be fine, but it is my understanding that inbound traffic on the leased line needs to know that it must route through x.50 in order to reach the servers located in the DMZ. I will configure the routing in the firewall. I have requested to the ISP that routing changes be made to x.2 so that all traffic for IP address x.51..63 be routed through my firewall located on x.50. The ISP says no, its not needed, it will work without it. I say he's an idiot. I went over his head to his manager, who also maintains that the routes are not needed to be added, and that its a waste of time, and I say that he's an idiot too. Can anyone out there confirm that these two guys are idiots, or is it me? TIA, Tom Crowe tom(a)songfield.com

4 4

openssh - restrict logins
by Luke Loh 05 Jul '02

05 Jul '02

Dear List I am running openssh and SuSEfirewall2 and would like to restrict ssh access to certain hosts. I have read the openssh docs and it seems I need to do this in hosts.allow, but this means that I need to have inetd / tcp-wrappers running. Is it possible to do this in SuSEfirewall2 without having inetd running? Regards Luke Loh

2 1

Re: [suse-security] SuSE-SA:2002:023
by Christian Laursen 05 Jul '02

05 Jul '02

Joerg Mayer <jmayer(a)loplof.de> writes: > On Tue, Jul 02, 2002 at 11:36:13PM +0200, Christian Laursen wrote: > > Is there a chance of an update which will work with both privsep and > > compression at some point in the near future, or will we have to wait for > > SuSE 8.1 to get that? > > It already DOES work, iff you have a 2.4 kernel. The problem is with > missing features in the shared mem implementation in 2.2 and earlier > kernels. Sorry, but on the three machines I have now tested it on, it doesn't. They are all running SuSE 8.0. One of them with the SuSE 2.4.18-4GB kernel, one with 2.4.18 and one with 2.4.19-rc1. On all of them I get the following message, when I start sshd: This platform does not support both privilege separation and compression Compression disabled -- Best regards Christian Laursen

6 8

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

05 Jul '02

> On Mon, Jul 01, 2002 at 10:12:21PM -0000, matthew zonderop wrote: >> my apache broke after the patch...had to reinstall the perl modules and >> uninstall the SSL module which i dont use anyway. >> but only took 5 mins..rcapache restart no problem... > If you tell us what exactly broke we might be able to work out if > anything was wrong and what! > Peter Peter, 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). 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 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. 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. 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. 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. 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. Mind you, I'm not complaining, just trying to give a hint where these problems might come from. cheers, oliver

3 2

openssh - restrict logins [SOLVED]
by Luke Loh 05 Jul '02

05 Jul '02

Thank you Andreas J Mueller and Alberto Santana for your quick responses. They both kindly pointed out to me that all I need to do to restrict SSH logins from a certain IP address in SuSEfirewall2 is: FW_TRUSTED_NETS="x.x.x.x/24,tcp,22 x.x.x.x,tcp,22" With this line, FW_SERVICES_EXT_TCP="22" is no longer required. Thank you again list for being an excellent resource. Luke Loh

1 0

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

04 Jul '02

> Hi, > On Wed, Jul 03, 2002 at 12:02:47PM +0200, Oliver Bleutgen wrote: >> >> > Strictly speaking those module updates should not have been necessary. >> >> I doubt that, from my own experiences. > Well I can not state that it works for all ~60 modules -- but for > mod_php4 and mod_perl it does. Peter, I have a small logical problem with that. You claim that the apache-1.3.19-115.rpm would run with modules of the original suse distribution, which is apache-1.3.12-120. Then, if this is so, why did SuSe release updated versions of all apache modules, when it first made the jump to apache-1.3.19-30? (that was the new version at that time, I did some searching). If the modules should work with apache 1.3.19-115 as you say, why shouldn't they have worked with apache 1.3.19-30? Either the update of the modules at that time was unnecessary, or it's still necessary today. (Or, there's some deep voodoo involved which makes the newer apache 1.3.19 "more compatible" with 1.3.12 modules than the old one - plausible?) >> 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. > You are right -- the older entries are superseded (i.e. removed) on that > web site (which is bad IMO). Indeed, why not just putting in a big fat warning that this upgrade is superseded. And just remove the links. > Also, looking on http://www.suse.de/de/support/security/ there is only > one apache announcement-- the last one. Apparently, we did not issue an > announcement at that time -- which would be bad IMO but I guess we might > not have had the same infrastructure at that time compared to now). Or > (!) we did issue the information about apache, but not in its own > announcement but in a > 2) pending vulnerabilities, solutions, workarounds > section. This way, the information is hard to find because the website > does list only the titles, not the affected package names, nor offers it > a way to search through the announcements. This is bad IMO as well. Well, at least we have rpm --changelog: * Fre Apr 20 2001 - poeml(a)suse.de - security update to Apache 1.3.19 due to a bug where, in the default installation, a very long path with many slashes could lead mod_negotiation and mod_dir/mod_autoindex to display a directory listing instead of the index.html.* files - don't define SINGLE_LISTEN_UNSERIALIZED_ACCEPT (it's already there) - update mod_ssl to corresponding version (2.8.2) - make mod_ssl subpackage require correct apache release number - don't use macro for Version how about a trip down memory lane? ;-) Oh, and about getting an older state of said webpage: http://web.archive.org/web/20011126194844/http://www.suse.com/us/support/do… As I wasn't affected from the above bug, I didn't upgrade. > I'll stimulate discussion about what kind of improvements would be > useful here. Be assured that your criticism is very helpful. [big snippage] >> 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. > It looks so. I don't believe it, but it's well possible. We might dig > into it further, but I can't promise anything. You don't need to, but taking my thoughts from above into consideration - as well as the fact that two other people on this list had the same problem - I'm quite sure that I'm right. If I am right, I'd think SuSE should take a look at their testing procedures, because they issued an update package which won't work on a stock install. And this is the first configuration on which I'd expect tests to be run. Perhaps it wasn't notified because apache will startup, but not work. Anyway, it's plausible that this incidend is caused mainly by growing problems and pains with aging versions of a distribution. In summary, two thing come to mind which would have helped me: - proper rpm dependencies well, I can install rpms, that's it, so I've no idea if this is doable in all cases. - A hint in the advisory to also install the newer apache modules. Ok, thanks for taking the time to answer my ramblings ;-). cheers, oliver

2 1

Help needed: no remote login (more Infos)
by Wilfried Philippi 04 Jul '02

04 Jul '02

Hello, >i have a problem with SuSe 8.0 and sshd or telnet. On the Serverconsole a >login as root or user is possible and i can login but over the Network it doesn't >work ..... >What is wrong? I use Putty as Client on the Windows >site. The Login Screen appears with login: and Password: I give the Username and the Password and then comes Access denied. Both the Username and Password are correct. Thanks for your Help. Wilfried

3 2

postfix address masquerading/header rewriting
by Hans-Peter Jansen 04 Jul '02

04 Jul '02

Hi, I red the postfix docs, but doesn't get a grip on my problem: In an installation of SuSE 7.2/postfix-20010228pl02-8 I suffer from following problem: Although I've activated masquerading, one can easily find the sending host in the Received: header incl. ip address. Is there any way to get rid of it: xyz = external domain int = internal domain Received: from xyz.de (sendinghost.int.de [192.168.15.14]) by mail.int.de (Postfix on LISA Linux (i386)) with ESMTP id C39416105 for <somebody(a)anywhere.com>; Thu, 4 Jul 2002 15:37:31 +0200 (CEST) Also I would like to get of the Sender: header, generated by Netscape Mail: Sender: sb(a)int.de The reason is very simple: hiding any internal details. Any hints highly appreciated. TIA, Hans-Peter

2 1

RE: [suse-security] Bind9 & resolver libs
by Reckhard, Tobias 04 Jul '02

04 Jul '02

> thanks Tobias, i am still unclear as to the possibility of exploiting > bind9 if recursion is limited/not allowed afaik the overflow occurs > at two of the variable parsers used by the resolver libs. If BIND9 uses the vulnerable resolver lib or implements the same code, it is vulnerable. If it doesn't, it isn't. That having been said, if you're worried about BIND being exploitable now and in the future, which I would be, then dump BIND and switch to something more secure. Such as djbdns. You'll still need to resolve the issue on the DNS clients, though. On a sidenote, proxy firewalled infrastructures don't require the workstations to perform DNS lookups at all, the proxy handles that for them. > and > also afaik > bind9 answers from cache anyway. So? I don't see your meaning. > the reason i am sceptical at > this stage > is one of my production boxen running only (SuSE) patched apache and > bind9 (80 & 53) has been r00ted. I don't believe it runs only those two apps.. ;-) [box r00ted by unknown avenue of attack] Post-breakin forensics can be tough (and therefore expensive). I believe we (secunet, the company I work for) have done some of it in the past, so if it's important enough to you, we could perhaps come to a deal, but it probably won't be cheap.. I sincerely hope the list doesn't read this as an advertisement of any sort, it's not meant that way. Tobias

3 2