[SECURITY] [DSA-138-1] Remote execution exploit in gallery
-BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-138-1 [EMAIL PROTECTED] http://www.debian.org/security/ Wichert Akkerman August 1, 2002 - Package: gallery Problem type : remote exploit Debian-specific: no A problem was found in gallery (a web-based photo album toolkit): it was possible to pass in the GALLERY_BASEDIR variable remotely. This made it possible to execute commands under the uid of web-server. This has been fixed in version 1.2.5-7 of the Debian package and upstream version 1.3.1. - Obtaining updates: By hand: wget URL will fetch the file for you. dpkg -i FILENAME.deb will install the fetched file. With apt: deb http://security.debian.org/ stable/updates main added to /etc/apt/sources.list will provide security updates Additional information can be found on the Debian security web-pages at http://www.debian.org/security/ - Debian GNU/Linux 2.2 alias potato - - Potato does not contain the gallery package Debian GNU/Linux 3.0 alias woody - Woody was released for alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0.dsc Size/MD5 checksum: 577 34188f0145b780cabc087dc273710428 http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5.orig.tar.gz Size/MD5 checksum: 132099 1a32e57b36ca06d22475938e1e1b19f9 http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0.diff.gz Size/MD5 checksum: 7125 707ec3020491869fa59f66d28e646360 Architecture independent packages: http://security.debian.org/pool/updates/main/g/gallery/gallery_1.2.5-7.woody.0_all.deb Size/MD5 checksum: 132290 8f6f152a45bdd3f632fa1cee5e994132 - -- - Debian Security team [EMAIL PROTECTED] http://www.debian.org/security/ Mailing-List: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBPUh3FqjZR/ntlUftAQEuJgL/Z9inFQxyaUZHvMqhyyPCBzORFbN4Edgu 67Ue5TXeNpZ4rDSgHAKnKBjeHnA4sw1qhubJlFLwzJVshJHrDbP1IXtesA77VEhx 6nM0V2aWX4HrZVO/OJS57IjbB1/vmrTc =n6mV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
service enablement via mail and otp?
Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. It seems like a fairly straightforward thing to implement but I'm not itching to maintain any code, so I was hoping there was something out there that does this already. I've looked around a bit but haven't turned up anything -- does anyone here know of anything similar out there already? [1] Specifically, I'm thinking that sshd might be a nice thing to have off most of the time on some of my systems.
changelog.Debian and security advisories
Yo! Would it make sense if new packages uploaded as part of handling a DSA would include the DSA number in the changelog.Debian? When I do an upgrade after seeing a DSA, it's sometimes not enirely clear to me if it's already the version mentioned in the DSA or if my mirror did not pick it up yet. (Yes, I can check the version number, but usually that means I have to go back and look at the DSA again.) [cc: me please because I'll be away the next 2 weeks] cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
help
RE: Updated Package List
Hi there, some of you suggested to remove portmap in order close some more port and thereby increase security. Since I never really understood what the pormapper was doing, I though I could do without it. However, once I tried to uninstall the package with dselect, I got a dependency issue saying that netbase suggests on portmap. Is that something I can ignore? Thanks for your help.
Re: error msg
On Wed, 31 Jul 2002, Dale Amon wrote: Since you brought the subject up... :-) Does anyone have a good way of dealing with daemons that use unpredictable port numbers? I have particular headaches with NFS, gdomap, and just recently SmokePing started doing it. I like to start off with a drop of everything and then open the absolute minimal requirements. INCLUDING LOOPBACK. So has anyone found a good way to deal with the unpredictable daemons? I think that netfilter helpers exist to enable connection tracking on RPC services, but these helpers did not make it (yet) in the official kernels from kernel.org nor in the debian sources. There is a sourceforge project, called the WOFL, which is a working functionally overloaded kernel with all sorts of optional patches integrated in it, but I am a bit reluctant to use it on a production machine. What I would _really_ like is a debian-style kernel-patch-netfilter package, to be able to smoothly integrate only the patches I need. Mosix (and openmosix, for that matter) and freeswan kernel patches are already available as well done debian packages, I hope we will see something like it for the netfilter patch-o-matic optional patches soon... Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 248 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _
Re: Updated Package List
To my knowledge you can safely ignore it. I'm always purging the package on every server installation I did since I know my servers don't use rpc at all. - Markus On Wed, Jul 31, 2002 at 08:46:38AM +0200, Jens Hafner wrote : some of you suggested to remove portmap in order close some more port and thereby increase security. Since I never really understood what the pormapper was doing, I though I could do without it. However, once I tried to uninstall the package with dselect, I got a dependency issue saying that netbase suggests on portmap. Is that something I can ignore? Thanks for your help. -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Fabian hwaaraSick: unsignificant hwaaraSick Fabian: can you be more precise? Fabian hwaaraSick: negligible
Re: Updated Package List
Jens Hafner [EMAIL PROTECTED] writes: some of you suggested to remove portmap in order close some more port and thereby increase security. Since I never really understood what the pormapper was doing, I though I could do without it. However, once I tried to uninstall the package with dselect, I got a dependency issue saying that netbase suggests on portmap. Is that something I can ignore? Thanks for your help. Yes. Only if a package (pre-)depends on another package you can not ignore it. Packages that are merely recommended or suggested should always be removable without breaking things (unless you specifically activated functionality that depends on the presence of such packages of course). -- Olaf MeeuwissenEPSON KOWA Corporation, ECS GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH
Re: changelog.Debian and security advisories
Previously Adrian 'Dagurashibanipal' von Bidder wrote: Would it make sense if new packages uploaded as part of handling a DSA would include the DSA number in the changelog.Debian? Half the time we don't know the DSA number when creating the package. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
linux random capabilities ...
hello people, i was talking to a friend, and he was describing the inability of PC based security devices to have proper pseudo-random number generation. This sounds to me that i needed some investigation. My general question is: does someone ever heard about any type of cryptographic attack using flaws in the random number generation ? Is there (even therically) possibilites to be able to guess those numbers ? I know that some protocols add some more randomness (like ipsec, using the last cyphered block in the antropy pool etc..), but i'd like to have a clear idea on how secure those mechanims are. Finally, i read here and there some work on hardware random generation devices (based on radio activity readings, or diods based devices or whatever), is there anyone with some experience with those ? thanks, cheers, JeF -- - Jean-Francois Dive -- [EMAIL PROTECTED]
Re: Some more port closing questions
On Wed, Jul 31, 2002 at 08:24:50AM +0900, [EMAIL PROTECTED] wrote: Hi, From: Rick Moen [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Tue, 30 Jul 2002 16:21:18 -0700 Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Kind of off-topic here, but I've been wondering for a while [1] whether the portmap package would be made to not install by default. I'd been wondering the same thing. Beyond that, I've been hoping that, at some point in the future, Debian won't cause network daemons to autostart in the default runlevel just because they've been installed. E.g., maybe the dpkg --configure step could prompt for that decision. Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; Apart from the starting by default issue: Why not just remove the appropriate symlinks S* in the directory /etc/rc2.d/ (or whatever runlevel you get into by default). Keep the scripts in /etc/init.d so you can start them by hand later. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some more port closing questions
Hi, From: Mathias Palm [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 11:23:55 +0200 On Wed, Jul 31, 2002 at 08:24:50AM +0900, [EMAIL PROTECTED] wrote: Hi, From: Rick Moen [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Tue, 30 Jul 2002 16:21:18 -0700 Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Kind of off-topic here, but I've been wondering for a while [1] whether the portmap package would be made to not install by default. I'd been wondering the same thing. Beyond that, I've been hoping that, at some point in the future, Debian won't cause network daemons to autostart in the default runlevel just because they've been installed. E.g., maybe the dpkg --configure step could prompt for that decision. Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; Apart from the starting by default issue: Why not just remove the appropriate symlinks S* in the directory /etc/rc2.d/ (or whatever runlevel you get into by default). Keep the scripts in /etc/init.d so you can start them by hand later. I used to do this but after a while I got tired of doing it manually and having to think about the implementation details of runlevels (i.e. the S* and K* stuff). It's really an interface issue (apart from the default issue). On a related note, I just ran dselect and noticed rcconf -- may be that's what I want (-; I'll have to check that out.
Re: Some more port closing questions
On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove AIUI the reasoning is that if you install a package including a daemon you are assumed to want the daemon to run. update-rc.d allows you to modify that assumption. Frank -- Home Page: URL:http://thingy.apana.org.au/~fjc/ Not the Scientology Home Page: URL:http://xenu.apana.org.au/ntshp/
Re: linux random capabilities ...
On Wed, Jul 31, 2002 at 07:51:03PM +1000, Jean-Francois Dive wrote: hello people, i was talking to a friend, and he was describing the inability of PC based security devices to have proper pseudo-random number generation. This sounds to me that i needed some investigation. My general question is: does someone ever heard about any type of cryptographic attack using flaws in the random number generation ? Is there (even therically) possibilites to be able to guess those numbers ? I know that some protocols add some more randomness (like ipsec, using the last cyphered block in the antropy pool etc..), but i'd like to have a clear idea on how secure those mechanims are. Short answer: Linux mainly uses interrupt timings as an entropy source, from devices that are fairly unpredictable. Assuming those are secure, the entropy pool is protected by a SHA hash of it's state when something needs random bits. (afaik) a SHA hash has no know weaknesses, with the exception of brute force which is simply too big to attempt. Long answer: read drivers/char/random.c from your nearest linux source tree. Finally, i read here and there some work on hardware random generation devices (based on radio activity readings, or diods based devices or whatever), is there anyone with some experience with those ? -- Adam Olsen, aka Rhamphoryncus
Re: Telnet information.
Quoting Jay Kline ([EMAIL PROTECTED]): I maay be wrong, but dont the SSH clients need that banner to be able to identify what version to use? Yes; the major/minor combination tells the client which protocol versions can be used. The latest phrack has some interesting information about that as well :) Greets, Robert -- ( o Linux Generation o ) ///\finger [EMAIL PROTECTED] for my GnuPG/PGP key./\\\ \V_/\_V/ Fluor zarq: i'll be gentle :]
Re: Telnet information.
On Wed, Jul 31, 2002 at 01:58:59PM +0200, Robert van der Meulen wrote: Quoting Jay Kline ([EMAIL PROTECTED]): I maay be wrong, but dont the SSH clients need that banner to be able to identify what version to use? Yes; the major/minor combination tells the client which protocol versions can be used. The latest phrack has some interesting information about that as well :) But you can use the sshd_config and ssh_config to allow only the version you want.
Re: Some more port closing questions
Hi, From: Frank Copeland [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:33:37 + (UTC) On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove From update-rc.d(8), I take it this: removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already - update-rc.d checks for this. I don't think that's what I want -- I want the software installed, just not started by default. I believe it's not that uncommon to install some software for testing purposes (at least this is often the case for me) -- in this kind of situation, you don't necessarily want the software to be running all of the time. In addition, if you're using a laptop which you power on and off w/ regular frequency (such as a few times a day), all daemons starting up at boot presents an inconvenient situation. Relying on myself to turn things off whenever I boot is prone to error and writing custom scripts to automate this is not a good practice from a maintenance perspective. IMHO it really ought to be part of the OS' capabilities. Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. I particularly like NetBSD's approach of not enabling any network daemons by default -- it requires an explicit decision on the part of the system administrator to have a network daemon start up. Just me two cents (-;
Re: service enablement via mail and otp?
On Wed, Jul 31, 2002 at 02:01:14PM +0200, Marcin Owsiany wrote: On Wed, Jul 31, 2002 at 01:37:30PM +0900, [EMAIL PROTECTED] wrote: Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. Recently I have seen someone posting an URL to his program which does something like that. It used GPG. I can't find the post, but I think you could find it looking for keywords like mail execution remote etc.. I guess it was this list, but I'm not sure. That someone could have been me: http://www.karl.jorgensen.com/smash Note: This is not production quality (yet). I use it myself on a couple of machines and find it useful. Testers and bugreports are welcome. Eyes on the source to find security weaknesses are in high demand. Read the man-page. Caveat Emptor. -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: SomeLamer what's the difference between chattr and chmod? SomeGuru SomeLamer: man chattr 1; man chmod 2; diff -u 1 2 | less -- Seen on #linux on irc pgpfYhXNVtDTh.pgp Description: PGP signature
Re: Some more port closing questions
On Wed, Jul 31, 2002 at 07:06:09PM +0900, [EMAIL PROTECTED] imagined: On a related note, I just ran dselect and noticed rcconf -- may be that's what I want (-; I'll have to check that out. rcconf is simple and works very well for me - FYI. Cheers, Raymond -- You deserve to be able to cooperate openly and freely with other people who use software. You deserve free software. -Richard M. Stallman, Free Software Foundation, http://www.fsf.org pgp3s5jFI6yz3.pgp Description: PGP signature
Re: Some more port closing questions
On Wed, 31 Jul 2002 [EMAIL PROTECTED] wrote: Hi, From: Frank Copeland [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:33:37 + (UTC) On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove From update-rc.d(8), I take it this: removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already - update-rc.d checks for this. I don't think that's what I want -- I want the software installed, just not started by default. [snip] The -f takes care of that. It makes the update-rc.d ignore the check for an init-script in /etc/init.d regards, Thomas -- Every increase in the size of government necessitates a decrease in an individual's freedom. -- Christian Harold Fletcher Riley
Re: Some more port closing questions
On Wed, Jul 31, 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: I don't think that's what I want -- I want the software installed, just not started by default. (...) FYI: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6 I wonder why I wrote it? :) Javi
Re: Security Stats
On Wed, Jul 24, 2002 at 08:03:44PM -0400, Phillip Hofmeister wrote: All, I am doing a college Honor's project on different distributions. Data on Debian and it's security fixes would be helpful if it is available. I would be looking for anythings useful in particular, the following: How many security fixes each quarter for the past 2 or 3 quearters. How many packages have been supported during said time^ Mean time until security update. If this information is available it would be VERY useful BTW, I read yesterday mjcox [1] diary entry in Advogato [2] before I write mine [3]. You might want to get in touch with him and ask him about his current work on this issue :) Javi [1] http://advogato.org/person/mjcox/ [2] http://advogato.org/person/mjcox/diary.html?start=78 [3] http://www.advogato.org/person/jfs/diary.html?start=9
Re: Some more port closing questions
On Wed, 31 Jul 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. Boy...you should get together withthe folks on debian-devel that say the install asks TOO many questions for a beginner to Linux...it would make a good flame war G -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import
Re: Telnet information.
Here's the link to the Phrack article. http://www.phrack.org/show.php?p=59a=11 It's a really good read, and what they are suggesting would affect the entire implementation of SSH, not just OpenSSH or SSH.com. It can't be fixed from the config file, as they are not talking about the protocols 1 or 2. -Anne This one time, Dale Amon wrote: On Wed, Jul 31, 2002 at 01:58:59PM +0200, Robert van der Meulen wrote: Quoting Jay Kline ([EMAIL PROTECTED]): I maay be wrong, but dont the SSH clients need that banner to be able to identify what version to use? Yes; the major/minor combination tells the client which protocol versions can be used. The latest phrack has some interesting information about that as well :) But you can use the sshd_config and ssh_config to allow only the version you want. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ pgp7xg3aJEZIw.pgp Description: PGP signature
Re: linux random capabilities ...
On Wednesday 31 July 2002 06:08, Adam Olsen wrote: Short answer: Linux mainly uses interrupt timings as an entropy source, from devices that are fairly unpredictable. Assuming those are secure, the entropy pool is protected by a SHA hash of it's state when something needs random bits. (afaik) a SHA hash has no know weaknesses, with the exception of brute force which is simply too big to attempt. untrue, consider the attack against Netscape's ssl implementation consider: Ian Goldberg and David Wagner, Randomness and the Netscape Browser, Dr.Dobbs Journal, January 1996, p.66 http://www.ddj.com/documents/s=965/ddj9601h/9601h.htm Long answer: read drivers/char/random.c from your nearest linux source tree. Finally, i read here and there some work on hardware random generation devices (based on radio activity readings, or diods based devices or whatever), is there anyone with some experience with those ? yeah, I dont' know much about it but an article exists on P4's with a PRNG on them.. If anyone can provide some more feedback on this I'd love to hear them out, I myself have not had time to read the article I'm about to link or do any research on this whatso ever. www.g0thead.com/papers/Cryptography/IntelRNG.pdf www.g0thead.com/ssl_notes.txt unfinished research on ssl - I apologize on any wrong information provided in this text as I said it's unfinished research and all comments/corrections/flames are welcome :) -- -- Orlando Padilla http://www.g0thead.com/xbud.asc 'A woman drove me to drink and I didn't even have the courtesy to thank her' -wa --
Re: linux random capabilities ...
Jean-Francois Dive [EMAIL PROTECTED] wrote: i was talking to a friend, and he was describing the inability of PC based security devices to have proper pseudo-random number generation. This sounds to me that i needed some investigation. My general question is: does someone ever heard about any type of cryptographic attack using flaws in the random number generation ? There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot Apparently there was an attack on early Netscape browsers that attacked the PRNG; see http://www.counterpane.com/yarrow.html There's a white paper on the topic there too. I think TCP sequence number prediction might be another example - see http://www.engarde.com/software/seqnum.php The linux kernel keeps an `entropy pool', which is stirred every time you press a key, access the disk, move the mouse, and with a patch from Robert Love's site (http://www.tech9.net/rml/linux/), every time the network is used too (very necessary for servers in racks IMHO). You can get random numbers out via /dev/random or /dev/urandom. These are cryptographically strong, though they don't come out at one hell of a rate. Unless, of course, your Intel motherboard has a hardware entropy collector (gets its numbers from ambient heat fluctuations, apparently). And you have turned that option on in the Linux kernel compile. In the userspace side of things, there's the Math::TrulyRandom Perl module, which uses fluctuations in the system timer to get some of that much-loved entropy. This takes some time but also produces pretty good random numbers. -- Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ 7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc 278A A425 30A9 05B5 2F13 The end move in politics is always to pick up a gun. BUCKMINSTER FULLER
CERT advisories
The most recent CERT advisory is about a vulnerability in OpenSSL. At the end of the advisory there's a link to RedHat who already has a patch ready.. Does anyone know what it would take to let the Debian community in the loop? I suppose this might let information out in the open before it was intended, but it doesn't seem fair that Debian should lag behind because we're an open community, does it? Or am I missing something? -- Søren HansenLinuxkonsulent I/S Open source specialist http://www.linuxkonsulent.dk My code (if any) in this post is copyright 2002, Søren Hansen and may be copied under the terms of the GNU General Public License signature.asc Description: Dette er en digitalt underskrevet brevdel
Re: CERT advisories
This one time, S?ren Hansen wrote: The most recent CERT advisory is about a vulnerability in OpenSSL. At the end of the advisory there's a link to RedHat who already has a patch ready.. Does anyone know what it would take to let the Debian community in the loop? I suppose this might let information out in the open before it was intended, but it doesn't seem fair that Debian should lag behind because we're an open community, does it? Or am I missing something? You must be missing something. $ openssl version OpenSSL 0.9.6e 30 Jul 2002 $ uname -a Linux swamp 2.4.17 #1 Fri Feb 22 11:08:36 PST 2002 i686 unknown unknown GNU/Linux I'm running Woody on my boxes. -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ pgpUbMpXAFh1W.pgp Description: PGP signature
Re: CERT advisories
Søren, please visit http://www.debian.org/security/ More specifically: http://www.debian.org/security/2002/dsa-136 On 31 Jul 2002, Søren Hansen wrote: The most recent CERT advisory is about a vulnerability in OpenSSL. At the end of the advisory there's a link to RedHat who already has a patch ready.. Does anyone know what it would take to let the Debian community in the loop? I suppose this might let information out in the open before it was intended, but it doesn't seem fair that Debian should lag behind because we're an open community, does it? Or am I missing something? -- Søren HansenLinuxkonsulent I/S Open source specialist http://www.linuxkonsulent.dk My code (if any) in this post is copyright 2002, Søren Hansen and may be copied under the terms of the GNU General Public License [-] Steve Mickeler [ [EMAIL PROTECTED] ] [|] Todays root password is brought to you by /dev/random [+] 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F
Re: Telnet information.
On Wed, Jul 31, 2002 at 08:12:00AM -0700, Anne Carasik wrote: Here's the link to the Phrack article. http://www.phrack.org/show.php?p=59a=11 It's a really good read, and what they are suggesting would affect the entire implementation of SSH, not just OpenSSH or SSH.com. It can't be fixed from the config file, as they are not talking about the protocols 1 or 2. Perhaps, but one should always change Protocol 1,2 to just Protocol 2 in both ssh_config and sshd_config. If someone only speaks P1, you really don't want to talk to them at all. Of course first make sure you are upgraded on your own clients and servers/
Re: CERT advisories
## Anne Carasik ([EMAIL PROTECTED]): $ openssl version OpenSSL 0.9.6e 30 Jul 2002 $ uname -a Linux swamp 2.4.17 #1 Fri Feb 22 11:08:36 PST 2002 i686 unknown unknown GNU/Linux I'm running Woody on my boxes. On that box, you are faster than security.debian.org. I have 0.9.6c (from openssl_0.9.6c-2.woody.0_i386.deb), which should be the fixed version according to http://www.debian.org/security/2002/dsa-136 Otherwise feel free to tell me what I missed. Regards, cmt -- Spare Space
Re: Telnet information.
Hi there, This one time, Dale Amon wrote: Perhaps, but one should always change Protocol 1,2 to just Protocol 2 in both ssh_config and sshd_config. If someone only speaks P1, you really don't want to talk to them at all. There's no debating that. The article doesn't refer to that--it refers to basic functionality of Secure Shell. -Anne -- .-.__.``. Anne Carasik, System Administrator .-.--. _...' (/) (/) ``' gator at cacr dot caltech dot edu (O/ O) \-' ` -==.', Center for Advanced Computing Research ~`~~ pgp8KRZfv8ond.pgp Description: PGP signature
Re: CERT advisories
Søren Hansen [EMAIL PROTECTED] writes: The most recent CERT advisory is about a vulnerability in OpenSSL. At the end of the advisory there's a link to RedHat who already has a patch ready.. Does anyone know what it would take to let the Debian community in the loop? There is no update from Red Hat yet which fixes the ASN.1 vulnerability, BTW. You have to read the advisories rather carefully these days. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
SunRPC Vulnerability
Funny. We were just discussing about portmap, and now this: http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20823 Is Debian vulnerable? regards, Thiemo Nagel
Re: Some more port closing questions
Hi, From: Thomas J. Zeeman [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 14:55:25 +0200 (CEST) On Wed, 31 Jul 2002 [EMAIL PROTECTED] wrote: Hi, From: Frank Copeland [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:33:37 + (UTC) On 30 Jul 02 23:24:50 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ah, that would be nice too. I know that the first thing I usually do when I boot my laptop is to stop a bunch of daemons that started up at boot (-; # update-rc.d -f somedaemon remove From update-rc.d(8), I take it this: removes any links in the /etc/rcrunlevel.d directories to the script /etc/init.d/name. The script must have been deleted already - update-rc.d checks for this. I don't think that's what I want -- I want the software installed, just not started by default. [snip] The -f takes care of that. It makes the update-rc.d ignore the check for an init-script in /etc/init.d Thanks for pointing that out (-;
Re: Some more port closing questions
Hi, From: Phillip Hofmeister [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 10:49:44 -0400 On Wed, 31 Jul 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: Perhaps update-rc.d or rcconf (as I posted earlier) can be used to get the desired behavior -- but I do think that being asked by default at installation time whether to start stuff up at boot time is better behavior than the current behavior. Boy...you should get together withthe folks on debian-devel that say the install asks TOO many questions for a beginner to Linux...it would make a good flame war G It seems like you could just have a mode w/o many/any questions and a mode that asks all the questions that are available -- i.e. Beginners can have a beginner's mode of installation, and non-beginners can have a non-beginner installation mode...no? Frankly, I don't like have to answer the same questions over and over though -- I'm hoping the automated installation procedures improve so I can just use those (I'm not complaining mind you). In the mean time, I've found that partimage is finally usable for my current situation (-;
Re: Some more port closing questions
Hi, From: Javier Fernández-Sanguino Peña [EMAIL PROTECTED] Subject: Re: Some more port closing questions Date: Wed, 31 Jul 2002 15:00:51 +0200 On Wed, Jul 31, 2002 at 09:25:40PM +0900, [EMAIL PROTECTED] wrote: I don't think that's what I want -- I want the software installed, just not started by default. (...) FYI: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6 I wonder why I wrote it? :) It's a nice explanation of the current state of things, isn't it? Did you read what I wrote about testing and have you noticed the comments about starting by default issue? I wonder why I wrote some of them? (-; Seriously though, I think in this case it comes down to a difference in philosophy. I'll just shut up and make do.
Re: linux random capabilities ...
On Wed, Jul 31, 2002 at 10:26:36AM -0500, Orlando wrote: On Wednesday 31 July 2002 06:08, Adam Olsen wrote: Short answer: Linux mainly uses interrupt timings as an entropy source, from devices that are fairly unpredictable. Assuming those are secure, the entropy pool is protected by a SHA hash of it's state when something needs random bits. (afaik) a SHA hash has no know weaknesses, with the exception of brute force which is simply too big to attempt. untrue, consider the attack against Netscape's ssl implementation consider: Ian Goldberg and David Wagner, Randomness and the Netscape Browser, Dr.Dobbs Journal, January 1996, p.66 http://www.ddj.com/documents/s=965/ddj9601h/9601h.htm Netscape doesn't use /dev/random, it uses a pseudo-random number generator. Pseudo-rngs aren't random, and the developers should be shot for doing it. Anything wanting cryptographically secure random numbers needs to use something like /dev/random. Long answer: read drivers/char/random.c from your nearest linux source tree. Finally, i read here and there some work on hardware random generation devices (based on radio activity readings, or diods based devices or whatever), is there anyone with some experience with those ? yeah, I dont' know much about it but an article exists on P4's with a PRNG on them.. If anyone can provide some more feedback on this I'd love to hear them out, I myself have not had time to read the article I'm about to link or do any research on this whatso ever. www.g0thead.com/papers/Cryptography/IntelRNG.pdf It looks like the P4 has a hardware RNG, not a psuedo-rng (which would be useless, and could be implimented in software easily). As far as the linux /dev/random is concerned, that hardware RNG is just another source of entropy. It has the advantage that it may be used in situations where there's no other source, but either way you just get random data out of it. www.g0thead.com/ssl_notes.txt unfinished research on ssl - I apologize on any wrong information provided in this text as I said it's unfinished research and all comments/corrections/flames are welcome :) -- Adam Olsen, aka Rhamphoryncus
Re: service enablement via mail and otp?
Hi, From: Karl E. Jorgensen [EMAIL PROTECTED] Subject: Re: service enablement via mail and otp? Date: Wed, 31 Jul 2002 13:47:16 +0100 On Wed, Jul 31, 2002 at 02:01:14PM +0200, Marcin Owsiany wrote: On Wed, Jul 31, 2002 at 01:37:30PM +0900, [EMAIL PROTECTED] wrote: Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. Recently I have seen someone posting an URL to his program which does something like that. It used GPG. I can't find the post, but I think you could find it looking for keywords like mail execution remote etc.. I guess it was this list, but I'm not sure. That someone could have been me: http://www.karl.jorgensen.com/smash Note: This is not production quality (yet). I use it myself on a couple of machines and find it useful. Testers and bugreports are welcome. Eyes on the source to find security weaknesses are in high demand. Read the man-page. Caveat Emptor. This could be nice...too nice for me perhaps (-; I've downloaded a copy and taken a quick look at the man page -- I didn't notice anything about mechanisms for dealing w/ replay attacks in the man page -- are there any? The reason I like the OTP design for my particular situation is that I don't want to carry around a PGP key [1] and I don't want to mess w/ doing some kind of round-trip-challenge-response thing via mail to deal w/ potential replay attacks. I'm also more comfortable w/ only allowing limited command execution -- specifically, only starting a single-session-only sshd (perhaps stopping sshd too) -- so that worse case, someone can only start sshd on a machine I'm looking after. Any plans for limiting the commands to be executed? [1] I've got OTP calculators for my PDA which I'm fine w/ carrying. Actually, what I don't want is to carry around a secret key and a corresponding device to do the encryption/signing/decryption (perhaps some day PDAs will do this comfortably). I'm not about to place a secret key of mine on someone else's machine...
Re: SunRPC Vulnerability
Hi, - Original Message - From: Thiemo Nagel [EMAIL PROTECTED] To: Debian-security@lists.debian.org Sent: Wednesday, July 31, 2002 4:03 PM Subject: SunRPC Vulnerability Funny. We were just discussing about portmap, and now this: http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20823 Is Debian vulnerable? regards, Thiemo Nagel That is funny, I was just thinking there was a new RPC exploit out. Seems scans on port 111 have become a more popular entry in my logs these days. Thanks for the info. :-) -Brandon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service enablement via mail and otp?
On Thu, Aug 01, 2002 at 08:09:31AM +0900, [EMAIL PROTECTED] wrote: Hi, From: Karl E. Jorgensen [EMAIL PROTECTED] Subject: Re: service enablement via mail and otp? Date: Wed, 31 Jul 2002 13:47:16 +0100 On Wed, Jul 31, 2002 at 02:01:14PM +0200, Marcin Owsiany wrote: On Wed, Jul 31, 2002 at 01:37:30PM +0900, [EMAIL PROTECTED] wrote: Hi, For some time, I've been toying w/ the idea of putting together something that would allow me to trigger the starting/stopping of various services [1] via a mail message containing some kind of OTP. Recently I have seen someone posting an URL to his program which does something like that. It used GPG. I can't find the post, but I think you could find it looking for keywords like mail execution remote etc.. I guess it was this list, but I'm not sure. That someone could have been me: http://www.karl.jorgensen.com/smash Note: This is not production quality (yet). I use it myself on a couple of machines and find it useful. Testers and bugreports are welcome. Eyes on the source to find security weaknesses are in high demand. Read the man-page. Caveat Emptor. This could be nice...too nice for me perhaps (-; I've downloaded a copy and taken a quick look at the man page -- I didn't notice anything about mechanisms for dealing w/ replay attacks in the man page -- are there any? No. I have to admit that I hadn't even thought about replay attacks :-(. I'll have to see what methods others have employed to avoid them (or think up a probably-less-secure method myself). Thinking about it: this would definitely be a good thing to add to smash. At some point I did ask on this list for where to find QA resources and got a couple of good answers. But unfortunately I haven't yet had time to follow up on them. The reason I like the OTP design for my particular situation is that I don't want to carry around a PGP key [1] and I don't want to mess w/ doing some kind of round-trip-challenge-response thing via mail to deal w/ potential replay attacks. Hm... GPG *does* have a --symmetric option, which seems to not use keys at all. Assuming that a suitable method for generating (and keeping-in-sync) passphrases between your PDA and smash, do you think that would be suitable for you? This probably implies storing/generating acceptable passphases locally (for smash) in clear-text... [ Almost going off-topic for this list now...] I'm also more comfortable w/ only allowing limited command execution -- specifically, only starting a single-session-only sshd (perhaps stopping sshd too) -- so that worse case, someone can only start sshd on a machine I'm looking after. Any plans for limiting the commands to be executed? Not yet. But it should be reasonably simple to add extensions to check the script immediately before execution. I'd prefer to implement such extensions as separate scripts. I like that idea. One more on my TODO list. However, I *do* have plans to allow commands to be mime-decoded and executed under a different user. This is mostly to ringfence any bugs in the mime decoding (which I suspect is not strong security-wise). This would also help to protect ~/.gnupg/* and ~/.procmailrc. [1] I've got OTP calculators for my PDA which I'm fine w/ carrying. Actually, what I don't want is to carry around a secret key and a corresponding device to do the encryption/signing/decryption (perhaps some day PDAs will do this comfortably). I'm not about to place a secret key of mine on someone else's machine... Which OTP calculator (and PDA) do you use? I've got a PDA too, and this might be handy for me too... [ This is probably OT for this list...] -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: What the scientists have in their briefcases is terrifying. -- Nikita Khruschev pgpndSW8IrYbE.pgp Description: PGP signature
