November 1999 - openSUSE Security - openSUSE Mailing Lists

Re: [suse-security] nfs-exports ro are writeable
by tschweikle＠FIDUCIA.de 23 Nov '99

23 Nov '99

Lutz.Jaenicke(a)aet.TU-Cottbus.DE wrote: > On Tue, Nov 23, 1999 at 10:18:29AM +0100, tschweikle(a)FIDUCIA.de wrote: >> We found out, that nfs exports may be writeable. Exports file: >> >> /home (rw,no_all_squash,no_root_squash) >> /usr (ro) >> >> On a remote machine as root: >> >> mount -t nfs myserver:/usr /mnt >> md /mnt/xyz >> ll -d /mnt/xyz >> drwx------ 6 root root 1024 Nov 22 13:26 xyz >> >> rm -rf /mnt/xyz >> ll -d /mnt/xyz >> drwx------ 6 root root 1024 Nov 22 13:26 xyz Arrgh! This should have been: ls: x: Datei oder Verzeichnis nicht gefunden Just copied the wrong line! Excuse! >> Shouldn't be, shouldn't it? >> >> System: SuSE 6.2, no fixes or patches applied. > > What is the problem? You tried to delete it With the example above I had the right to create it... what schouldn't be possible for a fs exported ro either. > and it is still there, so > you could not write. You ommited any kind of messages possibly generated > during the rm -rf procedure. There are no messages - no messages are good news. Meaning no errors. > That "w" is displayed in the list of rights > does not mean, that you really can do it :-) You can also burn a CD with > the "w" bit sets and it will be nevertheless really difficult to write :-) That is correct, while the 'w' reflects only the state of the 'w' bit on the reomte fs. Not the permission it is exported with. > Please make also sure, that you understand the concept of root->nobody > mapping when using NFS. /usr isn't writable localy by 'nobody'. Shouldn't be writable by 'nobody' mounted remote. -- Thomas

2 1

nfs-exports ro are writeable
by tschweikle＠FIDUCIA.de 23 Nov '99

23 Nov '99

Hi! We found out, that nfs exports may be writeable. Exports file: /home (rw,no_all_squash,no_root_squash) /usr (ro) On a remote machine as root: mount -t nfs myserver:/usr /mnt md /mnt/xyz ll -d /mnt/xyz drwx------ 6 root root 1024 Nov 22 13:26 xyz rm -rf /mnt/xyz ll -d /mnt/xyz drwx------ 6 root root 1024 Nov 22 13:26 xyz Shouldn't be, shouldn't it? System: SuSE 6.2, no fixes or patches applied. -- Thomas

2 1

Web based email
by Chrissy LeMaire 23 Nov '99

23 Nov '99

Anyone have any recommendations for a secure web-based email program? I use APOP authentication, so I'm running into a bit of a problem.. I may have to go back to regular Password authentication program :| If you've had good experiences with any web based email programs (hopefully, something quick to setup), please let me know about it. *random info* I only have 5 friends who use the service.. so the load isnt really an issue (my machine is a 166 with 32 megs of sdram)..

3 2

Attempts at an old hack...
by Karsten Johansson 22 Nov '99

22 Nov '99

Does everyone on this list get these lame-brain email attempts at hacks from days-gone-by? Sheez. The hack is some years old. Does it still work anywhere? I just wonder why anyone would even try repeatedly if it didn't work the first time... I just keep getting the bounce messages from the suse bot. ______________________________________________________ Get your free web-based email at http://www.xoom.com Birthday? Anniversary? Send FREE animated greeting cards for any occasion at http://greetings.xoom.com

1 0

Re: [suse-security] Help, my system has been hacked!
by E_u_R_Frohne＠t-online.de 21 Nov '99

21 Nov '99

Hello, the problem I had could be solved with your help. I would like to thank everyone who answered me. It was a workstation not properly set up for DHCP while no DHCP-Server is in my Network. Once again :Thank you! Regards Rainer

1 0

SuSE Security Announcement - syslogd (a1)
by Thomas Biege 18 Nov '99

18 Nov '99

-----BEGIN PGP SIGNED MESSAGE----- _____________________________________________________________________________ SuSE Security Announcement - syslogd (a1) Package: syslogd-1.3.33 (a1) Date: Thu Nov 18 14:00:29 CET 1999 Affected SuSE versions: 6.2 and 6.3 Vulnerability Type: local denial-of-service attack SuSE default package: yes Other affected systems: all Linux systems using the syslog daemon ______________________________________________________________________________ A security hole was discovered in the package mentioned above. Please update as soon as possible or disable the service if you are using this software on your SuSE Linux installation(s). Other Linux distributions or operating systems might be affected as well, please contact your vendor for information about this issue. Please note, that that we provide this information on an "as-is" basis only. There is no warranty whatsoever and no liability for any direct, indirect or incidental damage arising from this information or the installation of the update package. _____________________________________________________________________________ 1. Problem Description The syslogd server uses a Unix Domain stream socket (/dev/log) for receiving local log messages via syslog(3). Unix Domain stream sockets are non connection-less, that means, that one process is needed to serve one client. 2. Impact By opening alot of local syslog connections a user could stop the system from responding. 3. Solution Updated the package from our FTP server. ______________________________________________________________________________ Please verify these md5 checksums of the updates before installing: c9a9e0f8fc4e29daf30f8a735ae333ab syslogd-1.3.33-9.alpha.rpm (AXP, 6.1) 3104e26a8b474e215ed703b7c4d48888 syslogd-1.3.33-9.i386.rpm (x86, 5.3) a13be12a75232f2f62f51fb1cae26fc0 syslogd-1.3.33-9.i386.rpm (x86, 6.1) fc29df9455288f40eb1e8dbd0f47d5b3 syslogd-1.3.33-9.i386.rpm (x86, 6.2) 869b7fedd5b52807f12b7f66e282002c syslogd-1.3.33-9.i386.rpm (x86, 6.3) ______________________________________________________________________________ You can find updates on our ftp-Server: ftp://ftp.suse.com/pub/suse/axp/update/6.1/a1/syslogd-1.3.33-9.alpha.rpm ftp://ftp.suse.com/pub/suse/i386/update/5.3/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.1/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/syslogd-1.3.33-9.i386.rpm ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/syslogd-1.3.33-9.i386.rpm or try the following web pages for a list of mirrors: http://www.suse.de/de/support/download/ftp/inland.html http://www.suse.de/de/support/download/ftp/ausland.html Our webpage for patches: http://www.suse.de/de/support/download/updates/index.html Our webpage for security announcements: http://www.suse.de/de/support/security/index.html If you want to report vulnerabilities, please contact security(a)suse.de ______________________________________________________________________________ SuSE has got two free security mailing list services to which any interested party may subscribe: suse-security(a)suse.com - moderated and for general/linux/SuSE security discussions. All SuSE security announcements are send to this list. suse-security-announce(a)suse.com - SuSE's announce-only mailing list. Only SuSE's security annoucements are sent to this list. To subscribe to the list, send a message to: <suse-security-subscribe(a)suse.com> To remove your address from the list, send a message to: <suse-security-unsubscribe(a)suse.com> Send mail to the following for info and FAQ for this list: <suse-security-info(a)suse.com> <suse-security-faq(a)suse.com> _____________________________________________________________________________ This information is provided freely to everyone interested and may be redistributed provided that it is not altered in any way. Type Bits/KeyID Date User ID pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de> - ------BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12Cg== =pIeS - ------END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBODQEOney5gA9JdPZAQG+owf/QKgKybnaz14TyH4A9kjydx/9ibPGkv3p wdcdPJi/7/OWrGEjbh1zgLqnkvUWBnD/Z3jgiDpwxnCuokQ4AvX/pgaDJOYGO/oe dVT6jg/e38HwP6lCVEmg8DvCBG7SbV7w3DW5b9Yv/c3xSvX9iEJ1RZxUpsqgPBfZ 1eHaRTtEklmeSItei3y7YfU/yqogKA11k0ozDH/5E95mwhbEl8OtwolDlWDc5fYb v5ySeXf+uk/2zqoDQ2g/nwOHs6bitRFbgnA0wD1UHxIqh/9cBd8xvXOKStw9hwax r/XyMfKbsksg8SC58DaAzSmDMAjwwaHdw4Xh81Lf0smfVZtq/eG0pA== =WZQd -----END PGP SIGNATURE-----

1 0

Re: [suse-security] SuSE ssh Distro in US
by Eilert Brinkmann 17 Nov '99

17 Nov '99

"Aaron K. Poffenberger" <I_hate_spam.akp(a)hypernote.com> wrote: > On a related note (security), two questions: 1) Do I need to have the > ident daemon on port 113 running? That port is currently open on the > external interface on my firewall. No. None of the usual services depends on the ident daemon. > And 2) from within inetd.conf, can I > set which interface(s) I want a particular service to bind to, or is it a > service-by-service config (as I've found with many, e.g., afpd)? AFAIK inetd always binds to all interfaces. Perhaps it's possible to use a wrapper which checks on which interface a connection is coming in -- never tried this. Service-by-service configs will only work for servers running in daemon mode. For inetd-controlled services inetd binds to the ports/interfaces, and inetd doesn't know about any service-specific configuration. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert(a)informatik.uni-bremen.de - eilert(a)tzi.org - eilert(a)linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/

7 6

Re: [suse-security] Re: identd (was: SuSE ssh Distro in US)
by Aaron K. Poffenberger 17 Nov '99

17 Nov '99

I like this group -- lots of good information (I decided to disable it). Thanks. --Aaron On 11/17/99 12:30, eilert(a)Informatik.Uni-Bremen.DE wrote: >Robert Casties <robert.casties(a)philo.unibe.ch> wrote: >> I second that. The tcp-wrapper can also be configured to only accept >> connections from hosts running ident. > >It's possible, but it will exclude many clients. I.e., users on >non-UNIX hosts (and on many UNIX hosts, too) will not be able to >access the service. There may be situations where this doesn't matter, >but for typical public FTP or web servers this seems inappropriate to >me. > >> In priciple you may have an interest yourself using ident because it makes >> it possible to find out which user on an specific machine is using a >> connection. In case of a breakin attempted from your machine it is >> possible to find the user account used to do it. > >In many cases, e.g. on hosts on which usually aren't many users logged >in simultanously, it's probably possible to identify the account by >other means (wtmp entries etc.). For private hosts with dialup >connections identd answers are completely meaningless. But, yes, I can >think of such situations where identd can be useful to identify >attackers. And in some environments the use of identd may make it a >little less simpler to spoof the sender of emails etc., but it's no >real protection. IMHO identd is of little use in most cases, >especially on dialup hosts. > >On the other hand identd can be a privacy issue, e.g., web servers can >use it to identify and track visitors. (There are a lot of other means >to achive this.) Theoretically it can be possible to conclude from an >identd reply (the user name) to the e-mail address of the user in some >cases. I don't know if this is done, and probably this method won't be >very efficient. However, I suppose that most web servers issuing >identd requests don't do this (only) for security reasons. > >> The ident answer can of >> course be spoofed and you might be liable anyway for things going on on >> your machine... > >Which means that the ident protocol should never be used for "secure" >authentication. However, it can be used for logging purposes, and >there are situations where this might be useful. > >It should not a major security risk to leave port 113 open. But I >don't see a great security improvement through identd in most >situations, that's why I tend to disable it. It can also be a solution >to restrict identd access to specific hosts/domains where it is >needed. > >Eilert >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik >eilert(a)informatik.uni-bremen.de - eilert(a)tzi.org - eilert(a)linuxfreak.com > http://www.informatik.uni-bremen.de/~eilert/ > >-- >To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com >For additional commands, e-mail: suse-security-help(a)suse.com >

1 0

bind 4 upgrade
by peter＠frontierflying.com 17 Nov '99

17 Nov '99

I applied the SuSE 6.1 bind 4 upgrade to our 6.0 installation as per the instructions. Now my daemon.log is filled with entries like this Nov 15 10:21:14 hangar named[11230]: ns_forw: query(pop.frontierflying.com) cont ains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63.2.53 :NS=128.63.2.53) Nov 15 10:38:58 hangar named[11230]: ns_forw: query(frontierflying.com) contains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63.2.53:NS= 128.63.2.53) Nov 15 10:50:11 hangar named[11230]: ns_forw: query(mail.frontierflying.com) con tains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63.2.5 3:NS=128.63.2.53) Nov 15 11:03:29 hangar named[11230]: ns_forw: query(frontierflying.com) contains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63.2.53:NS= 128.63.2.53) Nov 15 11:36:21 hangar named[11230]: ns_forw: query(payroll.frontierflying.com) contains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63. 2.53:NS=128.63.2.53) Nov 15 11:53:23 hangar named[11230]: ns_forw: query(kahuna.frontierflying.com) c ontains our address (HANGAR.FRONTIERFLYING.COM:209.193.9.208) learnt (A=128.63.2 .53:NS=128.63.2.53) I am also having problems with nslookup being unable to get the name of our name server root@hangar:/etc > nslookup *** Can't find server name for address 209.193.9.208: Server failed Default Server: husky.ptialaska.net Address: 209.193.30.245 I can force it to go back and use our primary name server but again this is new behavior since the bind 4 upgrade. Any ideas? Thank you peter peter stern Frontier Flying Service Inc. Network Administrator 5245 Airport Industrial Rd 907-474-1739 x249 Fairbanks AK 99709

1 0

Re: [suse-security] Re: identd (was: SuSE ssh Distro in US)
by Eilert Brinkmann 17 Nov '99

17 Nov '99

Robert Casties <robert.casties(a)philo.unibe.ch> wrote: > I second that. The tcp-wrapper can also be configured to only accept > connections from hosts running ident. It's possible, but it will exclude many clients. I.e., users on non-UNIX hosts (and on many UNIX hosts, too) will not be able to access the service. There may be situations where this doesn't matter, but for typical public FTP or web servers this seems inappropriate to me. > In priciple you may have an interest yourself using ident because it makes > it possible to find out which user on an specific machine is using a > connection. In case of a breakin attempted from your machine it is > possible to find the user account used to do it. In many cases, e.g. on hosts on which usually aren't many users logged in simultanously, it's probably possible to identify the account by other means (wtmp entries etc.). For private hosts with dialup connections identd answers are completely meaningless. But, yes, I can think of such situations where identd can be useful to identify attackers. And in some environments the use of identd may make it a little less simpler to spoof the sender of emails etc., but it's no real protection. IMHO identd is of little use in most cases, especially on dialup hosts. On the other hand identd can be a privacy issue, e.g., web servers can use it to identify and track visitors. (There are a lot of other means to achive this.) Theoretically it can be possible to conclude from an identd reply (the user name) to the e-mail address of the user in some cases. I don't know if this is done, and probably this method won't be very efficient. However, I suppose that most web servers issuing identd requests don't do this (only) for security reasons. > The ident answer can of > course be spoofed and you might be liable anyway for things going on on > your machine... Which means that the ident protocol should never be used for "secure" authentication. However, it can be used for logging purposes, and there are situations where this might be useful. It should not a major security risk to leave port 113 open. But I don't see a great security improvement through identd in most situations, that's why I tend to disable it. It can also be a solution to restrict identd access to specific hosts/domains where it is needed. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert(a)informatik.uni-bremen.de - eilert(a)tzi.org - eilert(a)linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/

1 0