August 2001 - openSUSE Security - openSUSE Mailing Lists

Fwd: NDN: [suse-security] Fwd: suse: sdbsearch.cgi vulnerability
by phil 02 Aug '01

02 Aug '01

Who is this another mail bounce? I didn't send this to anyone else. ---------- Forwarded Message ---------- Return-path: <> Received: from mail.nextra.at [195.170.70.19] by osbtown.com [208.1.39.12] with SMTP (MDaemon.v3.5.7.R) for <phil(a)osbtown.com>; Thu, 02 Aug 2001 04:20:28 -0700 Received: from city.magnet.at (city.nextra.at [195.170.70.79]) by mail.nextra.at (8.11.1/8.9.3/nextra) with ESMTP id f72BKNb27948 for <phil(a)osbtown.com>; Thu, 2 Aug 2001 13:20:23 +0200 (MEST) X-nextra-mail01-rcpt: <phil(a)osbtown.com> Message-id: <fc.0064b97f032bc5a63b9aca00b5c253b8.32bc5a7(a)city.magnet.at> Date: Thu, 02 Aug 2001 13:20:14 +0200 Subject: NDN: [suse-security] Fwd: suse: sdbsearch.cgi vulnerability X-FC-Icon-ID: 2031 X-FC-MachineGenerated: true To: phil(a)osbtown.com From: "Mailer-Daemon" <Mailer-Daemon(a)city.magnet.at> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MDRcpt-To: phil(a)osbtown.com X-MDRemoteIP: 195.170.70.19 X-Return-Path: X-MDaemon-Deliver-To: phil(a)osbtown.com Reply-To: "" Status: R X-Status: N Sorry. Your message could not be delivered to: Peter Mueller (1018) Sorry. Your message could not be delivered to: Peter Mueller (1018) -------------------------------------------------------

1 0

Problem with Tar file
by Luis José Fabbiani B. (SOPORTE) 01 Aug '01

01 Aug '01

Hi All, at present I have in my server installed SuSe 7.0 and I have a Tar file that I need to send to another server by ftp. The file has a size of 2.3GB, and when I try to send, it shows the following error o message: not a plain file (ftp). I have tried to compress the file with a gzip -9 and it shows the following error o messages: Value too large for defined data type. What do you suggest, I should do? Is there a limit on the capacity of files that can be sent as Tar by ftp? Is there a limit on the degree to which such a file can be compressed using gzip? Thanks for your help LJ

4 3

RE: [suse-security] automatic backups over ssh/scp
by Reckhard, Tobias 01 Aug '01

01 Aug '01

> > That depends on the situation. The private keys are on the SSH client > > machine, so if that is more secure than the SSH server, the setup is > more > > secure than with passwords being on the server. > > I don't think so. In my opinion i doesn't matter if you store a plaintext > password or a ssh-key, which is not secured by an password. > It depends on the security of the system that either one is stored on. In SSH, they are different, the passwords are stored on the SSH server, the private keys are stored on the client. So, if your client is more secure than the server, the public key file is more difficult to get than the password file. And vice versa, of course. > Once Mr. X get's > access to the file, he get's instantly access to the account which is > guarded > by them. > Exactly, but the difficulty in getting the file can be different, because we're talking about two different machines. I.e. one machine could be a public web server, while the other one is a heavily firewalled and IDS's and whetever'd machine in a room with several feet of concrete and steel all around it. I'd place a critical file on the second machine. Note that you need clear text stuff in some situations if you want to automate them and automation is necessary in quite a few situations. If that means an empty passphrase on an SSH private key, OK, but I make sure the machine the file is on is safe. > > The use of public key authentication is definitely a lot safer against > > No, I strongly disagree. By just using public key authentication you gain > *no* > benefit for security and aren't instantly safer. > Read the rest of the sentence. Public key authentication is safer than password authentication most of the time because only very few passwords have the entropy of a pair of public and private keys. Passphrases to private keys have to be protected, as do passwords. Private key files without a passphrase have to be protected in the same way. The difference is that passwords are usually stored on a central machine, while private keys are on the clients. However, the distinction between client and server is not a distinction in security per se. I believe there are quite a few web clients that are more secure than many web servers, for example. > If you use > public-key-mechanisms in a wrong way things get much worse! Especially ssh > can > be abused in many ways to undermine any security barriers. > Of course any scheme can be abused. There's no difference between public key mechanisms and passwords here. But how does this relate to the issue at hand? Cya Tobias

2 1

RE: [suse-security] automatic backups over ssh/scp
by James Wilkus 01 Aug '01

01 Aug '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Use public key authentication as opposed to hard coding the username and password. HTH - -----Original Message----- From: Lukas Feiler [mailto:lukas.feiler@endlos.at] Sent: Tuesday, July 31, 2001 8:35 AM To: suse-security(a)suse.com Subject: [suse-security] automatic backups over ssh/scp I want to do the following: backup all my sensitive date from my main server, pack it into one file and then get it transfered to my backup server. That's fine but my problem is that those two machines aren't in the same local network. So if I do not encrypt my data it would be (more or less) visible to everybody on the net (who has some hacking knowledge). But as I said this data is sensible (passwords, creditcards, ...)! So I thought of ssh or scp BUT how to automate this process of backing up? I would have to specify user AND password in my backup-script. How do specify a password for ssh / scp in a script?? Plese Help! Luke - -- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com For additional commands, e-mail: suse-security-help(a)suse.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBO2ank/fthvTDkNu3EQKWWgCggExK9y2TjSrQkN1d0RKN3NoTVucAnRAb BzjzlOPPbqo/JdMqZixzVCTI =waJ0 -----END PGP SIGNATURE-----

4 4

RE: test, please ignore
by Roman Drahtmueller 01 Aug '01

01 Aug '01

Ok, guys, by coincidence, I found that moron who sent autoreplies to just about everybody posting to the list. I've nuked him from the server. It was a hassle because he forwards his email traffic to a different account, which bounces to the sender address then, of course without validation if the recipient is listed in To: or Cc:. Very charming to hunt down in a few thousand email addresses of the list. On 1 Aug 2001, Ted Skeen wrote: > From: Ted S... <XXXX> > To: Roman Drahtmueller <draht(a)suse.de> > Date: 1 Aug 01 16:49:46 GMT > Subject: RE: test, please ignore > Reply-To: NoFwd(a)uadvg135.cms.usa.net > > I will be on vacation until August 16, 2001. > > Ted Skeen > > > > ____________________________________________________________________ > This message was sent using MyPalm. Get web and wireless email and calendaring at http://www.palm.com. > Roman. -- - - | Roman Drahtmüller <draht(a)suse.de> "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -

1 0

Webmin Issues
by telco soltn 01 Aug '01

01 Aug '01

Hello! I'm contemplating in installing webmin in my SuSE 7.1 are there any security issues that I should be aware about? what are its pros and cons? cheers! chris __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

1 0

RE: [suse-security] DNS: BIND vs djbdns
by Reckhard, Tobias 01 Aug '01

01 Aug '01

> I'm wondering, does anyone of you are using djbdns > (http://cr.yp.to/djbdns.html) instead of BIND? What are your thoughts. > Apart > from being vulnerable, BIND frequently crashed. > I'm still using BIND 8.2.3 (the bind8-8.2.3-92 RPM for SuSE 7.1) on my internal server, but am planning to switch the djbdns as soon as I manage to create an RPM from the source, which equates to "as soon as I have the time". I agree with the others that BIND shouldn't be crashing and even if it did, that shouldn't happen with a regularity even remotely close to what you're seeing. I've never had it crash on said internal server (and its backup machine, a 486dx33 with 8MB RAM..). However, I do believe you'll be safer in the long run by dumping it in favour of djbdns. BIND's code is a mess and huge, this seems to be indirectly acknowledged by the ISC themselves. Even though nobody knows of any current security problems, this kind of code is what spawns them regularly. Just look at the list of security related bugs that are being fixed between BIND9 versions.. BIND also has many quirks and shortcomings, uses solutions for problems that don't really fix the problem but instead create new problems, etc. djbdns isn't entirely good, for one it doesn't have as many features as BIND, though many are available as patches from independent contributors. It has a very lean code base, was coded with security in mind and adheres to the UNIX ideal of having small, specialized programs that work well together in a coherent manner. It's also very simple to get running and maintain. Some setups are more complicated than with BIND, e.g. you can't have a DNS server and a DNS forwarder on one IP address, the two are separated in djbdns. You have a separate program for zone transfers, but Dan Bernstein urges everyone to avoid them anyhow and instead use rsync over SSH to transfer zone data securely and more economically. If you're speculating on dumping BIND and going for djbdns, you need to free yourself from the BIND way of thinking. For openminded folks or those who'd like to be, this can be a good exercise. Cheers, Tobias

1 0