April 2000 - openSUSE Security - openSUSE Mailing Lists

How to decrypt shell code of an exploit?
by Frank Derichsweiler 18 Apr '00

18 Apr '00

Hi list, the box of a friend was hacked: /bin/ps /bin/login /bin/ls were replaced / trojaned. The original files were placed in /bin/bincp (which is not shown by ls, but cd into that dir works fine) Luckyly I found some source within a log of another machine. Comments show that there is an unsigned char shellcode[] = with some rows of "\x ...\x" numbers. I assume that there is the coding of a shell command. Unfortunately I do not know how to "read" the command. Translating the hex numbers into decimal and using an ASCII table does not give a usefull result. Any idea? Tips who to detect which root kit was used are welcome, too. TIA Frank

7 9

Postfix update.
by Normando Marcolongo 18 Apr '00

18 Apr '00

Hi! Can I use on my SuSE 6.3 the postfix rpm extracted from version 6.4? Thanks, Normando -- Normando [enemy] Marcolongo (iW6OWQ) [] normando(a)studenti.ing.uniroma1.it LUGRoma - IEEE S.B. Roma - ALU - ??? [] (AX.25) IW6OWQ(a)IW7BNO.IPUG.ITA.EU

1 0

IPSec(FreeSWAN) and watchguard
by Uwe A. P. Wuerdinger 18 Apr '00

18 Apr '00

Hi list, can anyone here say something about the interoperabilty between suse 6.4 and the Watchguard products (3DES). And do the new firewall scripts support the IPSec stuff? greats Uwe -- ConnecT GmbH WWW: http://www.connect-gmbh.de/

1 0

imapd4r1 v12.264 and Security Implications
by BobF 18 Apr '00

18 Apr '00

The following was posted on FreeBSD-Security today. I was interested in the official SuSE position since I run both OS's. Re: Fw: Re: imapd4r1 v12.264 (fwd) From: Robert Watson <rwatson(a)FreeBSD.ORG> To: Kris Kennaway <kris(a)FreeBSD.ORG>, "Michael S. Fischer" <michael(a)dynamine.net> Cc: security(a)FreeBSD.ORG On Mon, 17 Apr 2000, Kris Kennaway wrote: > According to the message I just read on bugtraq by the vendor, it doesn't > seem to be as bad as I described it above: imapd has dropped privileges by > the time it hits the vulnerability, so exploiting it will only give access > to the shell account of the user who has logged in to imap. This may still > be a problem in some installations, i.e. if they don't provide shell > access to their mail users on the imap server. I consider the post by the vendor in the bugtraq forum to be some sort of poor joke. At this point, it would appear that anyone who takes security seriously should use some other mail package, or risk their systems' integrity. In particular, the thing about chroot'ing to /tmp is fairly laughable. While partitioning can be a useful scheme for reducing risk, "/tmp" is not the place to chroot to, and chroot'ing is not a replacement for careful code auditing. The suggestion that stackguard should be required to make their software secure has wandered far beyond ``questionable,'' and well into the ``don't touch anything related to my system ever again.'' The University of Washington IMAP programmers have proven time and again that they are quite capable of releasing code that puts people's system's at risk. They also are reluctant to admit or fix the bugs, and have demonstrated poor understanding of systems security issues. In other words, they make the poorest of choices when it comes to selecting developers for security-sensitive software (i.e., remote mail access servers). Perhaps we should fedex the uw-imapd people to the OpenBSD camp for correctional treatment. Given that attitude of the developer, I would strongly recommend we mark the port as FORBIDDEN, and would also seriously consider any suggestion to simply drop it from the ports and packages collections. Robert N M Watson robert(a)fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services -- Bob F EMail FBob(a)wt.net A Truly Wise Man Never Plays Leapfrog With A Unicorn...

1 0

Re: [suse-security] /etc/rc.config sets umask to 022
by Volker Kuhlmann 16 Apr '00

16 Apr '00

Roman, > Setting the umask to 077 will cause you trouble on any unix (-like) > system. Better close directories that contain privacy-critical files. would you be able to give some examples? Setting /var/log to 700 is not common on linux systems I think. Volker

2 1

where is SSH or OpenSSH for 6.4?
by jonathan 16 Apr '00

16 Apr '00

I understand that SuSE is only supporting OpenSSH, where can I find an RPM and how-to for 6.4?

2 1

/etc/rc.config sets umask to 022
by Volker Kuhlmann 15 Apr '00

15 Apr '00

I just noticed that the /etc/rc.config script sets the umask to 022 (SuSE 6.3). It does not seem to be something which can be changed with yast, even when editing rc.config with yast directly. Considering that all system daemons get started with this umask, isn't that a rather bad choice? For example I don't want apache log files to be user-readable. Each time the log files get rotated and apache restarted, the logs would be created with permissions 644. Are there any daemons which create files and not explicitly set the permissions to user-readable if necessary? If not then there's no reason to run all of them with 022. Volker

2 1

Important information about firewals/SuSEfirewall
by marc＠suse.de 15 Apr '00

15 Apr '00

Hi folks, please take a note of the following information about the firewals/SuSEfirewall package: Current stable version is v2.1 which is available as an update rpm for 6.3 and 6.4 from the usual FTP servers. If you upgrade from 6.3 or the v1.4 update please note that you can't keep/use your old config file, because some variables were renamed and several features were added. Also the config file location has changed from /etc/rc.firewall to /etc/rc.config.d/firewall.rc.config ! Updating is recommended, however if everything works for you and you don't needed the extended options, you don't need to. A NEW BETA IS AVAILABLE! The current beta version is v2.3, which is available from http://www.suse.de/~marc Please note that several new features were added since v2.1 so it should be tested as much as possible. Everything added works for me, but please send an email if you use the beta and tell me if everything works for you or not! It is currently not planned to add more features, so testing is needed to get to another stable version. The following CHANGES were done to the 2.3: v2.3 15.04.00 * Added service restriction to the masquerading to e.g. allow internal machine only to port 80. This is also done via FW_MASQ_NETS - there is now an extended syntax available! old (and still valid): "10.0.0.0/8" new (extended syntax): "10.0.0.0/8,tcp,80" allows web only. etc. * Changed the ipmasqadm -I statements to -A because the original way did not work for some people. weird. please test. * Put more example configs to the EXAMPLES file * Beautified and enhanced the INSTALL script a bit v2.2 06.04.00 (alpha version) * Added the long awaited FW_SERVICE_SAMBA support! * Added FW_FORWARD_MASQ_{TCP,UDP} so people can make their webservers on the internal, masqueraded nets available to the internet. * Now masquerading timeouts are set * NOTE: changed the preconfigured value of FW_ALLOW_INCOMING_HIGHPORTS_{TCP,UDP} to "yes" * Renamed the file HOLES to PROBLEMS * Fixed some few typos Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc(a)suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C

1 0

apache log files are user-readable
by Volker Kuhlmann 15 Apr '00

15 Apr '00

With SuSE 6.3, apache creates its logfiles in /var/log with permissions 644, which is not really on. Access logs shouldn't be available to all users, at least not by default. Add this to /etc/permissons.local and run chkstat -set /etc/permissions.local # apache #Change the www for http.conf to root if you haven't created a www group. /etc/local/httpd.conf root.www 640 /var/log/httpd.access_log root.root 600 /var/log/httpd.error_log root.root 600 Volker

3 2

Re: [suse-security] apache log files are user-readable
by Volker Kuhlmann 15 Apr '00

15 Apr '00

> > 644, which is not really on. Access logs shouldn't be available to all > > users, at least not by default. > > Why not? Users can create WEB-pages, so these files are often usefull to > debug problems. If you want to create access statistics, (for example with > webalizer) you need to read httpd.access too. I don't see any security > hole... (please let me know, if you really find one) It's not directly a security problem, more a privacy one (but privacy is security-related). As such, users shouldn't have access to other users' or the system's access logs. At least not by default. Ask your ISP or web hoster whether you can have a copy of the access logs of all customers plus everyone else's and see how far you're going to get. If you have a good web hoster, they will provide you with *your own* logs only. Likewise for email - do you give transfer logs (date, time, sender, receiver, perhaps subject) to all users on your system? Certainly not. Volker

1 0