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
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
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/
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...
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
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
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
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
> > 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
