From web at 3dresearch.com Wed Feb 4 07:42:25 2009 From: web at 3dresearch.com (Janos Dohanics) Date: Wed Feb 4 07:42:32 2009 Subject: OT - Heartland Payment Systems Message-ID: <200902041003.38182.web@3dresearch.com> I came across this today: http://information-security-resources.com/2009/01/29/did-heartland-ceo-make-insider-trades/ The article discusses some questions about the security breach which occurred at Heartland Payment Systems. Among other things, the article says: ?Somehow, these guys went directly to the base level of the machine (to an area) that was not part of the file table for the disk? ?Somehow, they got around the operating system." I'm wondering what is suggested here? -- Janos Dohanics From smithi at nimnet.asn.au Wed Feb 4 19:08:25 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Feb 4 19:08:32 2009 Subject: OT - Heartland Payment Systems In-Reply-To: <200902041003.38182.web@3dresearch.com> References: <200902041003.38182.web@3dresearch.com> Message-ID: <20090205132745.S38905@sola.nimnet.asn.au> On Wed, 4 Feb 2009, Janos Dohanics wrote: > I came across this today: > > http://information-security-resources.com/2009/01/29/did-heartland-ceo-make-insider-trades/ > > The article discusses some questions about the security breach which occurred > at Heartland Payment Systems. Among other things, the article says: > > ??Somehow, these guys went directly to the base level of the machine (to an > area) that was not part of the file table for the disk?? > > ??Somehow, they got around the operating system." > > I'm wondering what is suggested here? Apart from poor grammar, to me it suggests that they're trying really hard to not reveal which version of Windows they're running .. Ian From BORJAMAR at SARENET.ES Thu Feb 5 01:31:08 2009 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Thu Feb 5 01:31:16 2009 Subject: MAC subsystem and ZFS? Message-ID: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> Hello, I'm trying to upgrade the configuration of some web services, already using the MAC subsystem, to use ZFS instead of UFS, but I see that ZFS doesn't support MAC labels, even for a whole filesystem, which would be fine for me, I don't need multilabel support. Any ideas? Have I missed anything? Borja. From rwatson at FreeBSD.org Sat Feb 7 14:21:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Feb 7 14:22:02 2009 Subject: MAC subsystem and ZFS? In-Reply-To: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> References: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> Message-ID: On Thu, 5 Feb 2009, Borja Marcos wrote: > I'm trying to upgrade the configuration of some web services, already using > the MAC subsystem, to use ZFS instead of UFS, but I see that ZFS doesn't > support MAC labels, even for a whole filesystem, which would be fine for me, > I don't need multilabel support. > > Any ideas? Have I missed anything? Hmmm. Sounds like a bug -- all file systems should be able to operate in single-label mode, even if they don't support EAs and multilabel mode. Could you describe the symptoms you're experiencing in a bit more detail? Robert N M Watson Computer Laboratory University of Cambridge From mail at maxlor.com Mon Feb 9 01:49:26 2009 From: mail at maxlor.com (Benjamin Lutz) Date: Mon Feb 9 01:49:33 2009 Subject: OPIE considered insecure Message-ID: <200902090957.27318.mail@maxlor.com> Hello, I run a firewall where I use OPIE one time passwords for external logins, figuring that this gives me some added protections if I ever need to access it from untrustworthy hosts. A message about the weakness of MD5 got me thinking that maybe a better algorithm could be used for OPIE, and I was delighted to see that some clever hacked has added SHA-1 support to it (although it's a bit under-documented). Then I noticed that the one time passwords don't increase in length with SHA-1. That's weird, since MD5 produces 128bit digests, while SHA-1 produces 160bit digests. So I had a closer look at how the one time passwords are used with in OPIE. I was a bit shocked to find out that OPIE truncates all digests to 64 bits, no matter which algorithm you use. Some quick research into the current speed of MD5 brute-forcing produced this result: http://img519.imageshack.us/my.php?image=eightni6.jpg This ^ was produced on a quad core machine with 4 eVGA 9800GX2 graphics cards, i.e. a top end gaming machine; it can calculate 3611.81 million md5 hashes per second. Using that machine and that speed as a baseline, it's possible to produce a rainbow table with all hashes that OPIE is ever going to use and produce within 16 years. If you can live with a thinned out rainbow table (say, because you can the observe the user enter 8 passwords), and your budget allows a small cluster of these machines, you quickly get into the range of months. Add a few iterations of moore's law... well, you get the point. So, is there an existing alternative one time password implementation that works on FreeBSD? Also, as a suggestion to the security team, maybe it's time to deprecate or remove OPIE? Cheers Benjamin From BORJAMAR at SARENET.ES Mon Feb 9 02:25:15 2009 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Mon Feb 9 02:25:22 2009 Subject: MAC subsystem and ZFS? In-Reply-To: References: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> Message-ID: <5CFEFF94-39B2-4CB6-9797-1F6B9EF73D41@SARENET.ES> On Feb 7, 2009, at 11:21 PM, Robert Watson wrote: >> I'm trying to upgrade the configuration of some web services, >> already using the MAC subsystem, to use ZFS instead of UFS, but I >> see that ZFS doesn't support MAC labels, even for a whole >> filesystem, which would be fine for me, I don't need multilabel >> support. >> >> Any ideas? Have I missed anything? > > Hmmm. Sounds like a bug -- all file systems should be able to > operate in single-label mode, even if they don't support EAs and > multilabel mode. Could you describe the symptoms you're > experiencing in a bit more detail? Indeed I can :) Sorry for the delay, a human nose-irritating virus, for which no known AV software exists, apart from patience, has kept me a bit parked this weekend :) I can read the MAC label from a ZFS dataset, but cannot change it. Example follows: # zfs create pool/test (indeed I can read the default label applied when creating it) # getfmac pool/test pool/test: biba/high,mls/low (but I cannot change it) # setfmac biba/equal,mls/equal /pool/test setfmac: labeling not supported in /pool/test (just in case it's a confusion because of being under "/pool", I try changing the mountpoint, still no success) # mkdir /testing # zfs set mountpoint=/testing pool/test # setfmac biba/equal,mls/equal /testing setfmac: labeling not supported in /testing This is a 7.1.RELEASE-p2 system. Thank you very much, Borja. From des at des.no Mon Feb 9 03:25:29 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Feb 9 03:25:37 2009 Subject: OPIE considered insecure In-Reply-To: <200902090957.27318.mail@maxlor.com> (Benjamin Lutz's message of "Mon, 9 Feb 2009 09:57:27 +0100") References: <200902090957.27318.mail@maxlor.com> Message-ID: <86r627988o.fsf@ds4.des.no> Benjamin Lutz writes: > I was a bit shocked to find out that OPIE truncates all digests to 64 bits, > no matter which algorithm you use. Some quick research into the current > speed of MD5 brute-forcing produced this result: > [...] > So, is there an existing alternative one time password implementation that > works on FreeBSD? Also, as a suggestion to the security team, maybe it's > time to deprecate or remove OPIE? Our current OPIE implementation is a piece of crap. Feel free to suggest (or write) a replacement. That being said, there is no reason why OPIE challenges and responses can't be extended to 128 bits or more. The only downside is that users won't be able to use existing key calculators; they'll have to use pre-generated response sheets. DES -- Dag-Erling Sm?rgrav - des@des.no From daniel at roe.ch Mon Feb 9 09:05:52 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Mon Feb 9 09:06:24 2009 Subject: OPIE considered insecure In-Reply-To: <200902090957.27318.mail@maxlor.com> References: <200902090957.27318.mail@maxlor.com> Message-ID: <20090209170550.GA60223@hobbes.ustdmz.roe.ch> Benjamin Lutz 2009-02-09: [...] > Then I noticed that the one time passwords don't increase in > length with SHA-1. That's weird, since MD5 produces 128bit > digests, while SHA-1 produces 160bit digests. So I had a closer > look at how the one time passwords are used with in OPIE. > > I was a bit shocked to find out that OPIE truncates all digests > to 64 bits, no matter which algorithm you use. Some quick > research into the current speed of MD5 brute-forcing produced > this result: > > http://img519.imageshack.us/my.php?image=eightni6.jpg > > This ^ was produced on a quad core machine with 4 eVGA 9800GX2 > graphics cards, i.e. a top end gaming machine; it can calculate > 3611.81 million md5 hashes per second. Using that machine and > that speed as a baseline, it's possible to produce a rainbow > table with all hashes that OPIE is ever going to use and > produce within 16 years. If you can live with a thinned out > rainbow table (say, because you can the observe the user enter > 8 passwords), and your budget allows a small cluster of these > machines, you quickly get into the range of months. Add a few > iterations of moore's law... well, you get the point. > > So, is there an existing alternative one time password > implementation that works on FreeBSD? Also, as a suggestion to > the security team, maybe it's time to deprecate or remove OPIE? While I agree that OPIE can be improved, I think that the current OPIE implementation is still much better than having to use passwords from untrusted machines. I also prefer current OPIE to copying SSH private keys to untrusted machines. So until there is a more secure alternative, I really don't think removing OPIE would have a positive effect on security. -- Daniel Roethlisberger http://daniel.roe.ch/ From lyndon at orthanc.ca Mon Feb 9 13:02:17 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon Feb 9 13:02:28 2009 Subject: OPIE considered insecure In-Reply-To: <20090209170550.GA60223@hobbes.ustdmz.roe.ch> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> Message-ID: > While I agree that OPIE can be improved, I think that the current > OPIE implementation is still much better than having to use > passwords from untrusted machines. I also prefer current OPIE to > copying SSH private keys to untrusted machines. So until there > is a more secure alternative, I really don't think removing OPIE > would have a positive effect on security. The machine you are logging IN TO does not require your private key, just your public key. --lyndon Linux -- Where Quantity is Job One! From lyndon at orthanc.ca Mon Feb 9 14:13:42 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon Feb 9 14:13:48 2009 Subject: OPIE considered insecure In-Reply-To: <20090209134738.G15166@treehorn.dfmm.org> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> Message-ID: > Right, but that's not the problem they're trying to solve. They're trying to > solve the problem of logging in _from_ an untrusted machine, to a trusted > machine. Okay, I got it backawrds. > So, an alternative might be to carry around a USB key with a one-time private > key, different from your normal private keys, and have the public key > command-squashed on the server to remove itself from authorized_keys before > running the shell. That's what I do -- multiple throw-away keys on a USB stick, for emergencies. However if you're that paranoid you better be carrying around your own set of ssh binaries on that stick as well. > You could generate several, each with a different passphrase (assuming that > you could manage to remember that many passphrases and which keys they go > with), and get a similar effect to printing out a card with the next ten OPIE > passwords. It's not that hard to come up with a scheme that lets you map from an identifier tagged to the private key to the corresponding password (in your head). It's a pain at the start, but once you've used a given scheme for a while it becomes second nature. Akso, note that you can get similar behaviour using K5 with one-off instances of your principal (e.g. lyndon.a6d5mps@EXAMPLE.ORG). The advantage here is that there are no key files involved (but you still want to carry a trusted kinit binary with you). The downside is that most sites don't have K5/GSSAPI enabled. And of those that do, a significant percentage of the implementations still don't to dynamic realm discovery, therefore you need a pre-existing arrangement to map your realm to the appropriate KDCs. --lyndon Happiness is a good martini, a good meal, a good cigar, and a good woman ... or a bad woman, depending on how much happiness you can stand. -- George Burns From freebsd-security at dfmm.org Mon Feb 9 14:20:29 2009 From: freebsd-security at dfmm.org (Jason Stone) Date: Mon Feb 9 14:20:37 2009 Subject: OPIE considered insecure In-Reply-To: References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> Message-ID: <20090209134738.G15166@treehorn.dfmm.org> >> I also prefer current OPIE to copying SSH private keys to untrusted >> machines. > The machine you are logging IN TO does not require your private key, > just your public key. Right, but that's not the problem they're trying to solve. They're trying to solve the problem of logging in _from_ an untrusted machine, to a trusted machine. So, an alternative might be to carry around a USB key with a one-time private key, different from your normal private keys, and have the public key command-squashed on the server to remove itself from authorized_keys before running the shell. You could generate several, each with a different passphrase (assuming that you could manage to remember that many passphrases and which keys they go with), and get a similar effect to printing out a card with the next ten OPIE passwords. -Jason From daniel at roe.ch Mon Feb 9 14:48:34 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Mon Feb 9 14:48:42 2009 Subject: OPIE considered insecure In-Reply-To: References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> Message-ID: <20090209224806.GB63675@hobbes.ustdmz.roe.ch> Lyndon Nerenberg 2009-02-09: > >Right, but that's not the problem they're trying to solve. > >They're trying to solve the problem of logging in _from_ an > >untrusted machine, to a trusted machine. > > Okay, I got it backawrds. > > >So, an alternative might be to carry around a USB key with a > >one-time private key, different from your normal private keys, > >and have the public key command-squashed on the server to > >remove itself from authorized_keys before running the shell. > > That's what I do -- multiple throw-away keys on a USB stick, > for emergencies. However if you're that paranoid you better be > carrying around your own set of ssh binaries on that stick as > well. My use case is primarily to log in from highly untrusted and malware infested systems. OPIE has been a usable solution to that problem. I'm primarily worried about keyloggers and USB memory stick content dumpers. OPIE fits that bill quite well. > >You could generate several, each with a different passphrase > >(assuming that you could manage to remember that many > >passphrases and which keys they go with), and get a similar > >effect to printing out a card with the next ten OPIE > >passwords. > > It's not that hard to come up with a scheme that lets you map > from an identifier tagged to the private key to the > corresponding password (in your head). It's a pain at the > start, but once you've used a given scheme for a while it > becomes second nature. > > Akso, note that you can get similar behaviour using K5 with > one-off instances of your principal (e.g. > lyndon.a6d5mps@EXAMPLE.ORG). The advantage here is that there > are no key files involved (but you still want to carry a > trusted kinit binary with you). The downside is that most sites > don't have K5/GSSAPI enabled. And of those that do, a > significant percentage of the implementations still don't to > dynamic realm discovery, therefore you need a pre-existing > arrangement to map your realm to the appropriate KDCs. I prefer OPIE also because it does not need anything fancy on the client side beyond a standard SSH2 client. -- Daniel Roethlisberger http://daniel.roe.ch/ From ipfreak at yahoo.com Mon Feb 9 14:53:24 2009 From: ipfreak at yahoo.com (gahn) Date: Mon Feb 9 14:53:31 2009 Subject: ipv6 and ipfw Message-ID: <856498.31257.qm@web52106.mail.re2.yahoo.com> Hi all: I have a station that has multiple interfaces. Some of interfaces run both ipv4 and ipv6. checked with man pages of rc.conf and it seems to be telling me that ipfw for ipv4 and ipv6 are two different processes and need two different scripts. Is it correct? Or anyone here can direct me for the web sites with more information? Thanks From Mark_Andrews at isc.org Mon Feb 9 15:14:13 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Feb 9 15:14:19 2009 Subject: ipv6 and ipfw In-Reply-To: Your message of "Mon, 09 Feb 2009 14:26:43 -0800." <856498.31257.qm@web52106.mail.re2.yahoo.com> Message-ID: <200902092314.n19NE3Dv026545@drugs.dv.isc.org> In message <856498.31257.qm@web52106.mail.re2.yahoo.com>, gahn writes: > Hi all: > > I have a station that has multiple interfaces. Some of interfaces run both ip > v4 and ipv6. checked with man pages of rc.conf and it seems to be telling me > that ipfw for ipv4 and ipv6 are two different processes and need two differen > t scripts. > > Is it correct? Or anyone here can direct me for the web sites with more infor > mation? > > Thanks The answer to that is version specific. IPFW2 includes support for IPv6 as well as IPv4 though not all the features are supported for IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From freebsd-security at dfmm.org Mon Feb 9 15:18:26 2009 From: freebsd-security at dfmm.org (Jason Stone) Date: Mon Feb 9 15:18:33 2009 Subject: OPIE considered insecure In-Reply-To: <20090209224806.GB63675@hobbes.ustdmz.roe.ch> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <20090209224806.GB63675@hobbes.ustdmz.roe.ch> Message-ID: <20090209150235.X15166@treehorn.dfmm.org> >> That's what I do -- multiple throw-away keys on a USB stick, for >> emergencies. However if you're that paranoid you better be carrying >> around your own set of ssh binaries on that stick as well. Your own SSH binaries don't help; you can sniff the TTYs (or whatever the Windows equivalent is for getting raw keystroke data at the kernel level) directly. Yes, in a strict sense, it's not possible to safely log in from an untrusted host. But in a practical sense, we can look at the common attacks. I assume that any given public Windows box (at the library, internet cafe, etc) has a keystroke logger, but I'm not (yet...) going to assume that any given Windows box has an agent that actively seizes SSH connections and trojans the remote end. Someday that may change, but in the meantime, most folks with low-security needs can reasonably assume that all data entered into an untrusted machine will be logged, but that no level of active attack will take place; so as long as nothing in your session is reusable/replayable, you're pretty safe. > I'm primarily worried about keyloggers and USB memory stick content > dumpers. If you keep just a single key at a time on the USB stick, and the key deletes itself from the server as soon as you use it, you don't care if it gets copied, because you only plug the stick in when you want to use that key, at which point the key immediately becomes useless. And if you trust crypto, and you have multiple keys each encrypted with a different passphrase, you probably still don't care if the USB stick gets copied. > I prefer OPIE also because it does not need anything fancy on the client > side beyond a standard SSH2 client. Agreed, and Kerberos must definitely be disqualified on this basis. But I've never seen an SSH client that doesn't allow keys, including Windows and Java-based clients. -Jason From ipfreak at yahoo.com Mon Feb 9 15:22:38 2009 From: ipfreak at yahoo.com (gahn) Date: Mon Feb 9 15:22:45 2009 Subject: ipv6 and ipfw In-Reply-To: <200902092314.n19NE3Dv026545@drugs.dv.isc.org> Message-ID: <416026.72989.qm@web52103.mail.re2.yahoo.com> Thanks Mark: Sorry I am using FreeBSD 7.1. Best --- On Mon, 2/9/09, Mark Andrews wrote: > From: Mark Andrews > Subject: Re: ipv6 and ipfw > To: ipfreak@yahoo.com > Cc: "freebsd security" > Date: Monday, February 9, 2009, 3:14 PM > In message > <856498.31257.qm@web52106.mail.re2.yahoo.com>, gahn > writes: > > Hi all: > > > > I have a station that has multiple interfaces. Some of > interfaces run both ip > > v4 and ipv6. checked with man pages of rc.conf and it > seems to be telling me > > that ipfw for ipv4 and ipv6 are two different > processes and need two differen > > t scripts. > > > > Is it correct? Or anyone here can direct me for the > web sites with more infor > > mation? > > > > Thanks > > The answer to that is version specific. IPFW2 includes > support for IPv6 as well as IPv4 though not all the > features > are supported for IPv6. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: > Mark_Andrews@isc.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" From lyndon at orthanc.ca Mon Feb 9 15:32:27 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon Feb 9 15:41:33 2009 Subject: OPIE considered insecure In-Reply-To: <20090209224806.GB63675@hobbes.ustdmz.roe.ch> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <20090209224806.GB63675@hobbes.ustdmz.roe.ch> Message-ID: > My use case is primarily to log in from highly untrusted and > malware infested systems. OPIE has been a usable solution to > that problem. I'm primarily worried about keyloggers and USB > memory stick content dumpers. OPIE fits that bill quite well. It does, but *only* if you are running your own trusted ssh binary. Preferably one that is statically linked, but even then you're subject to the kernel-based keystroke logging. >From what you're describing, I would be more inclined to carry a bootable OS on that USB stick and reboot into that. I have systems running OpenBSD that boot and run from 2GB USB sticks. There's no reason you couldn't do the same with FreeBSD. --lyndon The longest UNIX error code is ENAMETOOLONG. From Mark_Andrews at isc.org Mon Feb 9 16:12:34 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Feb 9 16:12:41 2009 Subject: ipv6 and ipfw In-Reply-To: Your message of "Mon, 09 Feb 2009 15:22:37 -0800." <416026.72989.qm@web52103.mail.re2.yahoo.com> Message-ID: <200902100012.n1A0CHLr027615@drugs.dv.isc.org> In message <416026.72989.qm@web52103.mail.re2.yahoo.com>, gahn writes: > Thanks Mark: > > Sorry I am using FreeBSD 7.1. > > Best FreeBSD 6's ipfw has IPv6 support so I presume 7's does as well. Note I build my kernel with the following options as I want forwarding. options IPFIREWALL options IPFIREWALL_FORWARD Mark > --- On Mon, 2/9/09, Mark Andrews wrote: > > > From: Mark Andrews > > Subject: Re: ipv6 and ipfw > > To: ipfreak@yahoo.com > > Cc: "freebsd security" > > Date: Monday, February 9, 2009, 3:14 PM > > In message > > <856498.31257.qm@web52106.mail.re2.yahoo.com>, gahn > > writes: > > > Hi all: > > > > > > I have a station that has multiple interfaces. Some of > > interfaces run both ip > > > v4 and ipv6. checked with man pages of rc.conf and it > > seems to be telling me > > > that ipfw for ipv4 and ipv6 are two different > > processes and need two differen > > > t scripts. > > > > > > Is it correct? Or anyone here can direct me for the > > web sites with more infor > > > mation? > > > > > > Thanks > > > > The answer to that is version specific. IPFW2 includes > > support for IPv6 as well as IPv4 though not all the > > features > > are supported for IPv6. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: > > Mark_Andrews@isc.org > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to > > "freebsd-security-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From ipfreak at yahoo.com Mon Feb 9 17:29:12 2009 From: ipfreak at yahoo.com (gahn) Date: Mon Feb 9 17:29:18 2009 Subject: ipv6 and ipfw In-Reply-To: <200902100012.n1A0CHLr027615@drugs.dv.isc.org> Message-ID: <147404.54014.qm@web52106.mail.re2.yahoo.com> Thanks Mark: my machine would load the modules when the system boots up. here is my rc.conf: firewall_enable="YES" firewall_script="/etc/ipfw.conf" firewall_logging="YES" does that matter? --- On Mon, 2/9/09, Mark Andrews wrote: > From: Mark Andrews > Subject: Re: ipv6 and ipfw > To: ipfreak@yahoo.com > Cc: "freebsd security" > Date: Monday, February 9, 2009, 4:12 PM > In message > <416026.72989.qm@web52103.mail.re2.yahoo.com>, gahn > writes: > > Thanks Mark: > > > > Sorry I am using FreeBSD 7.1. > > > > Best > > FreeBSD 6's ipfw has IPv6 support so I presume 7's > does as well. > > Note I build my kernel with the following options as I > want > forwarding. > > options IPFIREWALL > options IPFIREWALL_FORWARD > > Mark > > > --- On Mon, 2/9/09, Mark Andrews > wrote: > > > > > From: Mark Andrews > > > Subject: Re: ipv6 and ipfw > > > To: ipfreak@yahoo.com > > > Cc: "freebsd security" > > > > Date: Monday, February 9, 2009, 3:14 PM > > > In message > > > > <856498.31257.qm@web52106.mail.re2.yahoo.com>, gahn > > > writes: > > > > Hi all: > > > > > > > > I have a station that has multiple > interfaces. Some of > > > interfaces run both ip > > > > v4 and ipv6. checked with man pages of > rc.conf and it > > > seems to be telling me > > > > that ipfw for ipv4 and ipv6 are two > different > > > processes and need two differen > > > > t scripts. > > > > > > > > Is it correct? Or anyone here can direct me > for the > > > web sites with more infor > > > > mation? > > > > > > > > Thanks > > > > > > The answer to that is version specific. IPFW2 > includes > > > support for IPv6 as well as IPv4 though not all > the > > > features > > > are supported for IPv6. > > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: > > > Mark_Andrews@isc.org > > > _______________________________________________ > > > freebsd-security@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > > To unsubscribe, send any mail to > > > > "freebsd-security-unsubscribe@freebsd.org" > > > > > > > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: > Mark_Andrews@isc.org From Mark_Andrews at isc.org Mon Feb 9 17:34:48 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Feb 9 17:34:55 2009 Subject: ipv6 and ipfw In-Reply-To: Your message of "Mon, 09 Feb 2009 17:29:11 -0800." <147404.54014.qm@web52106.mail.re2.yahoo.com> Message-ID: <200902100134.n1A1Yh02029334@drugs.dv.isc.org> In message <147404.54014.qm@web52106.mail.re2.yahoo.com>, gahn writes: > > Thanks Mark: > > my machine would load the modules when the system boots up. here is my rc.con > f: > > firewall_enable="YES" > firewall_script="/etc/ipfw.conf" > firewall_logging="YES" > > does that matter? It depends on if you need the additional functionality. > --- On Mon, 2/9/09, Mark Andrews wrote: > > > From: Mark Andrews > > Subject: Re: ipv6 and ipfw > > To: ipfreak@yahoo.com > > Cc: "freebsd security" > > Date: Monday, February 9, 2009, 4:12 PM > > In message > > <416026.72989.qm@web52103.mail.re2.yahoo.com>, gahn > > writes: > > > Thanks Mark: > > > > > > Sorry I am using FreeBSD 7.1. > > > > > > Best > > > > FreeBSD 6's ipfw has IPv6 support so I presume 7's > > does as well. > > > > Note I build my kernel with the following options as I > > want > > forwarding. > > > > options IPFIREWALL > > options IPFIREWALL_FORWARD > > > > Mark > > > > > --- On Mon, 2/9/09, Mark Andrews > > wrote: > > > > > > > From: Mark Andrews > > > > Subject: Re: ipv6 and ipfw > > > > To: ipfreak@yahoo.com > > > > Cc: "freebsd security" > > > > > > Date: Monday, February 9, 2009, 3:14 PM > > > > In message > > > > > > <856498.31257.qm@web52106.mail.re2.yahoo.com>, gahn > > > > writes: > > > > > Hi all: > > > > > > > > > > I have a station that has multiple > > interfaces. Some of > > > > interfaces run both ip > > > > > v4 and ipv6. checked with man pages of > > rc.conf and it > > > > seems to be telling me > > > > > that ipfw for ipv4 and ipv6 are two > > different > > > > processes and need two differen > > > > > t scripts. > > > > > > > > > Is it correct? Or anyone here can direct me > > for the > > > > web sites with more infor > > > > > mation? > > > > > > > > > > Thanks > > > > > > > > The answer to that is version specific. IPFW2 > > includes > > > > support for IPv6 as well as IPv4 though not all > > the > > > > features > > > > are supported for IPv6. > > > > > > > > Mark > > > > -- > > > > Mark Andrews, ISC > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > PHONE: +61 2 9871 4742 INTERNET: > > > > Mark_Andrews@isc.org > > > > _______________________________________________ > > > > freebsd-security@freebsd.org mailing list > > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > > > To unsubscribe, send any mail to > > > > > > "freebsd-security-unsubscribe@freebsd.org" > > > > > > > > > > > > _______________________________________________ > > > freebsd-security@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > > To unsubscribe, send any mail to > > "freebsd-security-unsubscribe@freebsd.org" > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: > > Mark_Andrews@isc.org > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From des at des.no Wed Feb 11 03:47:31 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Feb 11 03:47:45 2009 Subject: OPIE considered insecure In-Reply-To: <20090209134738.G15166@treehorn.dfmm.org> (Jason Stone's message of "Mon, 9 Feb 2009 13:53:47 -0800 (PST)") References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> Message-ID: <86eiy5nqjz.fsf@ds4.des.no> Jason Stone writes: > Right, but that's not the problem they're trying to solve. They're > trying to solve the problem of logging in _from_ an untrusted machine, > to a trusted machine. If the machine you're logging in *from* is untrusted, you're SOL. Even with OPIE or similar mechanisms, somebody might piggyback on your SSH connection. The best you can do is boot from a CD or USB fob you prepared yourself, and even then, there might be a hardware key logger installed on the computer. DES -- Dag-Erling Sm?rgrav - des@des.no From daniel at roe.ch Wed Feb 11 04:22:09 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Wed Feb 11 04:22:22 2009 Subject: OPIE considered insecure In-Reply-To: <86eiy5nqjz.fsf@ds4.des.no> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <86eiy5nqjz.fsf@ds4.des.no> Message-ID: <20090211122200.GA86644@hobbes.ustdmz.roe.ch> Dag-Erling Sm?rgrav 2009-02-11: > Jason Stone writes: > > Right, but that's not the problem they're trying to solve. > > They're trying to solve the problem of logging in _from_ an > > untrusted machine, to a trusted machine. > > If the machine you're logging in *from* is untrusted, you're > SOL. Even with OPIE or similar mechanisms, somebody might > piggyback on your SSH connection. The best you can do is boot > from a CD or USB fob you prepared yourself, and even then, > there might be a hardware key logger installed on the computer. Or the BIOS trojaned. Your statement is of course correct, logging in from untrusted machines can never be secure. However, OPIE still raises the bar on the required capabilities for an attack (active, real-time attack versus passive keylogging / data dumping). -- Daniel Roethlisberger http://daniel.roe.ch/ From des at des.no Wed Feb 11 05:50:39 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Feb 11 05:50:47 2009 Subject: OPIE considered insecure In-Reply-To: <20090211122200.GA86644@hobbes.ustdmz.roe.ch> (Daniel Roethlisberger's message of "Wed, 11 Feb 2009 13:22:00 +0100") References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <86eiy5nqjz.fsf@ds4.des.no> <20090211122200.GA86644@hobbes.ustdmz.roe.ch> Message-ID: <86skmlm6aa.fsf@ds4.des.no> Daniel Roethlisberger writes: > Your statement is of course correct, logging in from untrusted > machines can never be secure. However, OPIE still raises the bar > on the required capabilities for an attack (active, real-time > attack versus passive keylogging / data dumping). This conversation reminds me of a flipchart outside the terminal room at an early BSDCon, with a list of passwords sniffed from the network and something like "if your password is listed below, you should consider using SSH" :) DES -- Dag-Erling Sm?rgrav - des@des.no From daniel at roe.ch Wed Feb 11 07:12:38 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Wed Feb 11 07:12:46 2009 Subject: OPIE considered insecure In-Reply-To: <86skmlm6aa.fsf@ds4.des.no> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <86eiy5nqjz.fsf@ds4.des.no> <20090211122200.GA86644@hobbes.ustdmz.roe.ch> <86skmlm6aa.fsf@ds4.des.no> Message-ID: <20090211151230.GA89737@hobbes.ustdmz.roe.ch> Dag-Erling Sm?rgrav 2009-02-11: > Daniel Roethlisberger writes: > > Your statement is of course correct, logging in from > > untrusted machines can never be secure. However, OPIE still > > raises the bar on the required capabilities for an attack > > (active, real-time attack versus passive keylogging / data > > dumping). > > This conversation reminds me of a flipchart outside the > terminal room at an early BSDCon, with a list of passwords > sniffed from the network and something like "if your password > is listed below, you should consider using SSH" :) :-) The technical "wrong" or "right" is just one aspect of security. Security is also about risk management; elimination being only one possible strategy for adequately dealing with risk. -- Daniel Roethlisberger http://daniel.roe.ch/ From mail at maxlor.com Wed Feb 11 09:22:02 2009 From: mail at maxlor.com (Benjamin Lutz) Date: Wed Feb 11 09:22:10 2009 Subject: OPIE considered insecure In-Reply-To: <200902090957.27318.mail@maxlor.com> References: <200902090957.27318.mail@maxlor.com> Message-ID: <200902111821.53437.mail@maxlor.com> Hello, I've been thinking about what to do about OPIE, and I see the following possibilities. (Note: this is mainly just a braindump to collect my thoughts; many details that seem obvious to me are omitted. I'm making it public because others might be interested in it too.) - Enhance OPIE to use larger internal hashes. Because of the way OPIE works, the user needs to input at least as many bits as OPIE uses internally, therefore increasing the hash length increases the inconvenience. If 5-letter words were added, this would give us 18, maybe 24 additional bits for a total of 82-88 bits; if two numeric digits (2-9, because 0 and 1 might be confused with O and l) are added to every word (JOHN43 BOAT59), this would give us 36 additional bits for a total of 100 bits. - Implement another algorithm: PPP. (https://www.grc.com/ppp.htm, no source available but algorithm is documented.) This system appears to have one weakness compared to OPIE: the secure 256-bit key needs to be stored on the host and is accessed frequently. There are several advantages though: the algorithm won't be brute-forced any time soon, and since the passwords have no dependencies to each other, they can each be very short (GRC suggests 4 characters). Also, the number of one time passwords that can be generated is unlimited (*). PPP Variant 1: The problem of the secure key being compromised could be solved by extending the algorithm as follows: the list of one time passwords is precalculated on the host, each password is hashed and only the hash is stored. This would remove the advantage (*) and also prevent recreation of a password list (but that's good, right?) PPP Variant 2: derive the secure 256-bit key from some user passphrase. This would allow password calculators. - Implement another algorithm: OTPW (http://www.cl.cam.ac.uk/~mgk25/otpw.html, implementation is GPL, algorithm is documented.) This system precalculates random independent passwords and stores their hashes. This then works the same as the PPP variant 1 described above. Password calculators are not possible. - Use pam_sotp (http://www.cavecanen.org/cs/projects/pam_sotp/, GPL, algorithm not documented). Seems be quite similar to OTPW. Some general thoughts: - The one time passwords should definitively be independent from each other; this allows very short passwords, which is much more convenient than OPIE is now. - I wonder if it makes sense to worry about races? (Attacker logs your key presses, then automatically logs in after you've entered the last character but before you've pressed enter.) Probably not, when there is the danger of the ssh binary being compromised? - OPIE prevents concurrent logins. Is it possible to allow them securely, without making DOS-by-password-exhaustion possible? Cheers Benjamin From rwatson at FreeBSD.org Wed Feb 11 09:52:15 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Feb 11 09:52:22 2009 Subject: MAC subsystem and ZFS? In-Reply-To: <5CFEFF94-39B2-4CB6-9797-1F6B9EF73D41@SARENET.ES> References: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> <5CFEFF94-39B2-4CB6-9797-1F6B9EF73D41@SARENET.ES> Message-ID: On Mon, 9 Feb 2009, Borja Marcos wrote: > On Feb 7, 2009, at 11:21 PM, Robert Watson wrote: > >>> I'm trying to upgrade the configuration of some web services, already >>> using the MAC subsystem, to use ZFS instead of UFS, but I see that ZFS >>> doesn't support MAC labels, even for a whole filesystem, which would be >>> fine for me, I don't need multilabel support. >>> >>> Any ideas? Have I missed anything? >> >> Hmmm. Sounds like a bug -- all file systems should be able to operate in >> single-label mode, even if they don't support EAs and multilabel mode. >> Could you describe the symptoms you're experiencing in a bit more detail? > > Indeed I can :) Sorry for the delay, a human nose-irritating virus, for > which no known AV software exists, apart from patience, has kept me a bit > parked this weekend :) > > I can read the MAC label from a ZFS dataset, but cannot change it. Example > follows: Hi Borja: This is the expected behavior for a single-label file system -- that is to say, a file system that doesn't support storing multiple labels. If EA support in ZFS is mature, it should be fairly straight forward to implement multi-label support. The following changes were made to UFS/UFS2 to support per-file label storage: (1) Implement VOP_SETLABEL for the file system using vop_stdsetlabel_ea in the any relevant vnode operation vectors: #ifdef MAC .vop_setlabel = vop_stdsetlabel_ea, #endif (2) Define a file system property, such as a superblock flack in UFS, that will persisently store whether or not the file system is configured for multilabel operation (so that singlelabel operation can still be supported): #define FS_MULTILABEL 0x20 /* file system is MAC multi-label */ (3) Trigger setting of MNT_MULTILABEL based on that flag being set: if ((fs->fs_flags & FS_MULTILABEL) != 0) { #ifdef MAC MNT_ILOCK(mp); mp->mnt_flag |= MNT_MULTILABEL; MNT_IUNLOCK(mp); #else printf("WARNING: %s: multilabel flag on fs but no MAC support\n", mp->mnt_stat.f_mntonname); #endif } (4) When vnodes become associated with particular file system objects, ensure that the vnode label has been properly set up from the EA data, such as in this code from ffs_vget: #ifdef MAC if ((mp->mnt_flag & MNT_MULTILABEL) && ip->i_mode) { /* * If this vnode is already allocated, and we're running * multi-label, attempt to perform a label association * from the extended attributes on the inode. */ error = mac_associate_vnode_extattr(mp, vp); if (error) { /* ufs_inactive will release ip->i_devvp ref. */ vput(vp); *vpp = NULL; return (error); } } #endif The utility routine mac_associate_vnode_extattr() should be called with the vnode lock held, and before any I/O (etc) can take place on the object so that appropriate security information is guaranteed to be available. (5) When a new object is allocated and a vnode is associated with it, ensure that a new label is created for the object and both set in the EA and loaded into the vnode label: #ifdef MAC if (dvp->v_mount->mnt_flag & MNT_MULTILABEL) { error = mac_create_vnode_extattr(cnp->cn_cred, dvp->v_mount, dvp, tvp, cnp); if (error) goto bad; } #endif Again, we have a utility routine, mac_create_vnode_extattr(), that does all the work, and is passed the parent directory object, mountpoint, creator credential, etc so that the new label can be derived and written to disk. This needs to happen before any I/O is possible on the vnode so the security information is available for access control. In UFS, this happens in two places -- general file create, and separately for directory create. (6) Cause VOP_PATHCONF to return an appropriate flag so applications know that per-file labeling is available: case _PC_MAC_PRESENT: #ifdef MAC if (ap->a_vp->v_mount->mnt_flag & MNT_MULTILABEL) *ap->a_retval = 1; else *ap->a_retval = 0; #else *ap->a_retval = 0; #endif (7) There may be some places where you need to explicitly disable MAC checking, such as internal calls to vn_rdwr() on directories, or name lookup, where there isn't a convenient privileged credential but the work is arguably on behalf of the file system. IO_NOMACCHECK can be used for vn_rdwr and NOMACCHECK for namei. I'm happy to help review patches and discuss this further; the hooks/utility routines were very much designed with UFS in mind, although intended to be generic enough to support other file systems, and we may want to revise them as we gain experience. Robert N M Watson Computer Laboratory University of Cambridge > > # zfs create pool/test > > (indeed I can read the default label applied when creating it) > # getfmac pool/test > pool/test: biba/high,mls/low > > (but I cannot change it) > # setfmac biba/equal,mls/equal /pool/test > setfmac: labeling not supported in /pool/test > > (just in case it's a confusion because of being under "/pool", I try changing > the mountpoint, still no success) > > # mkdir /testing > # zfs set mountpoint=/testing pool/test > # setfmac biba/equal,mls/equal /testing > setfmac: labeling not supported in /testing > > This is a 7.1.RELEASE-p2 system. > > Thank you very much, > > > > > > > > Borja. > From peterjeremy at optushome.com.au Wed Feb 11 10:07:15 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Feb 11 10:07:21 2009 Subject: OPIE considered insecure In-Reply-To: References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <20090209224806.GB63675@hobbes.ustdmz.roe.ch> Message-ID: <20090211180709.GB1467@server.vk2pj.dyndns.org> On 2009-Feb-09 15:30:33 -0800, Lyndon Nerenberg wrote: > From what you're describing, I would be more inclined to carry a bootable > OS on that USB stick and reboot into that. Keep in mind that libraries, internet cafes etc aren't going to be keen on you turning up with some (to them) random USB stick and wanting to reboot their pride-and-joy off it. I suspect your choices are to either use OPIE (or some adaption thereof) with ssh on an untrusted computer and assume that anything you type will be logged or carry your own trusted computer and use some form of wireless (3G, NextG etc) to communicate with your systems. Note that using very large sequence numbers should slow down an attacker (though only linerarly) since they still need to iterate MD5 by that many rounds. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090211/aea7b045/attachment.pgp From BORJAMAR at SARENET.ES Thu Feb 12 01:27:37 2009 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Thu Feb 12 01:27:45 2009 Subject: MAC subsystem and ZFS? In-Reply-To: References: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> <5CFEFF94-39B2-4CB6-9797-1F6B9EF73D41@SARENET.ES> Message-ID: <827FC0EC-0774-4957-A589-A0A566792DD9@SARENET.ES> On Feb 11, 2009, at 6:52 PM, Robert Watson wrote: > On Mon, 9 Feb 2009, Borja Marcos wrote: > >> On Feb 7, 2009, at 11:21 PM, Robert Watson wrote: >> >>>> I'm trying to upgrade the configuration of some web services, >>>> already using the MAC subsystem, to use ZFS instead of UFS, but I >>>> see that ZFS doesn't support MAC labels, even for a whole >>>> filesystem, which would be fine for me, I don't need multilabel >>>> support. >>>> Any ideas? Have I missed anything? >>> Hmmm. Sounds like a bug -- all file systems should be able to >>> operate in single-label mode, even if they don't support EAs and >>> multilabel mode. Could you describe the symptoms you're >>> experiencing in a bit more detail? >> >> I can read the MAC label from a ZFS dataset, but cannot change it. >> Example follows: > This is the expected behavior for a single-label file system -- that > is to say, a file system that doesn't support storing multiple > labels. If EA support in ZFS is mature, it should be fairly > straight forward to implement multi-label support. The following > changes were made to UFS/UFS2 to support per-file label storage: Hmm. But, expected to be unable to change the label for the whole filesystem? (ZFS dataset = filesystem) In my example, pool/test is a dataset, a separate filesystem. I'm not dealing with multi-label support and I know there's a serious problem to implement such EAs in ZFS, as far as I know. ZFS is designed to be interoperable, and a ZFS pool created in, say, FreeBSD or Mac OS X should be perfectly readable for, for example, Solaris. What happens to this kind of attributes that cannot be understood by the others? It's a pity that the usage of strong systems such as this MAC subsystem is only marginal... It's hard to standardize anything. Borja. From mail at maxlor.com Thu Feb 12 02:14:03 2009 From: mail at maxlor.com (Benjamin Lutz) Date: Thu Feb 12 02:14:12 2009 Subject: OPIE considered insecure In-Reply-To: <20090212104119.45583e6fcp63gcmc@webmail.leidinger.net> References: <200902090957.27318.mail@maxlor.com> <200902111821.53437.mail@maxlor.com> <20090212104119.45583e6fcp63gcmc@webmail.leidinger.net> Message-ID: <200902121113.58828.mail@maxlor.com> Hi Alexander, On Thursday 12 February 2009 10:41:19 Alexander Leidinger wrote: > - Implement something which is similar o freeauth.org, just better > implemented and without the "not so good" stuff / design decissions. > > Short: they need something you know (PIN) + something you have (e.g. > token, or mobile phone with java with some fixed key). You then enter > your arbitrary long PIN into the phone, and it will give you a time > limited key to login (so the time needs to be in sync to some extend). > On the machine you login you need the cleartext version of your PIN, > the fixed key, and ideally it saves the the PW you just used to login > to prevent a relogin with the same PW. If you've seen the remote login > tokens from RSA or similar, then you should get the idea what this is > about. I've stumbled accross freeauth.org while researching the subject. The reason I didn't consider it is because so far I've been just printing out my otps, and that's no longer possible with freeauth.org. And there are situations where I can't run a Java program on my phone, for example when I'm using the phone as a bluetooth modem. I'm not saying that time-based pws wouldn't be nice to have, it just goes in a different direction than OPIE, so it's not what I'm looking for at the moment. Also, the thought of having to write programs in J2ME again horrifies me :) > I wrote down a while ago the algorithm somewhere (based upon my own > thoughts how to do it, this was before I've seen freeauth, so it's > independent), and also thought about the bells and whistles (some > security pitfalls you need to think about). If you are interested in > implementing this (ideally with a BSD license for inclusion into the > base system) While I most probably won't implement freeauth.org, I'd still like to see your notes; the security pitfalls you considered are likely there for other algorithms too. Cheers Benjamin From Alexander at Leidinger.net Thu Feb 12 02:00:41 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Feb 12 04:22:47 2009 Subject: OPIE considered insecure In-Reply-To: <200902111821.53437.mail@maxlor.com> References: <200902090957.27318.mail@maxlor.com> <200902111821.53437.mail@maxlor.com> Message-ID: <20090212104119.45583e6fcp63gcmc@webmail.leidinger.net> Quoting Benjamin Lutz (from Wed, 11 Feb 2009 18:21:53 +0100): > Hello, > > I've been thinking about what to do about OPIE, and I see the following > possibilities. (Note: this is mainly just a braindump to collect my > thoughts; many details that seem obvious to me are omitted. I'm making it > public because others might be interested in it too.) [...] > - Implement another algorithm: OTPW [...] - Implement something which is similar o freeauth.org, just better implemented and without the "not so good" stuff / design decissions. Short: they need something you know (PIN) + something you have (e.g. token, or mobile phone with java with some fixed key). You then enter your arbitrary long PIN into the phone, and it will give you a time limited key to login (so the time needs to be in sync to some extend). On the machine you login you need the cleartext version of your PIN, the fixed key, and ideally it saves the the PW you just used to login to prevent a relogin with the same PW. If you've seen the remote login tokens from RSA or similar, then you should get the idea what this is about. I wrote down a while ago the algorithm somewhere (based upon my own thoughts how to do it, this was before I've seen freeauth, so it's independent), and also thought about the bells and whistles (some security pitfalls you need to think about). If you are interested in implementing this (ideally with a BSD license for inclusion into the base system) -- Oh, yeah, life goes on, long after the thrill of livin' is gone. -- John Cougar, "Jack and Diane" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From BORJAMAR at SARENET.ES Thu Feb 12 04:42:20 2009 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Thu Feb 12 04:42:28 2009 Subject: MAC subsystem and ZFS? In-Reply-To: References: <5F581D71-E6BF-487D-91F0-67EA6A21BA6E@SARENET.ES> <5CFEFF94-39B2-4CB6-9797-1F6B9EF73D41@SARENET.ES> Message-ID: On Feb 11, 2009, at 6:52 PM, Robert Watson wrote: > This is the expected behavior for a single-label file system -- that > is to say, a file system that doesn't support storing multiple > labels. If EA support in ZFS is mature, it should be fairly > straight forward to implement multi-label support. The following > changes were made to UFS/UFS2 to support per-file label storage: Hmm. I see, I start to understand, but... Suppose I have a system without any multilabel support enabled. Is it possible to assign a different MAC label than the default to a single filesystem? For instance: Imagine I have everything with a default label of biba/ high and I want a biba/equal label just for /tmp, which is a different filesystem. I've tried creating a policy file to be used with setfsmac but I am unable to change that default label. Am I doing anything wrong? Or is multilabel support mandatory in order to assign a n label to a filesystem? What I've been trying now (and without ZFS) is: (without multi-label support enabled for any filesystems) - mount a filesystem, say, into /filesystem - it has the default biba/high(low-high),mls/low(low-high) label - try to change the label for the filesystem. setfmac newlabel /filesystem (fails) create a policy.conf stating a label for the new filesystem /filesystem biba/equal,mls/equal and trying to apply it setfsmac -vxf policy.conf /filesystem (fails) setfsmac -vxf policy.conf / (fails) Doing anything wrong or it's just not possible to change the MAC label from the default for a whole filesystem without any multi-label support in the system? Thank you very much again, Borja. From josh at tcbug.org Fri Feb 13 08:41:12 2009 From: josh at tcbug.org (Josh Paetzel) Date: Fri Feb 13 08:41:19 2009 Subject: OPIE considered insecure In-Reply-To: <86skmlm6aa.fsf@ds4.des.no> References: <200902090957.27318.mail@maxlor.com> <20090209170550.GA60223@hobbes.ustdmz.roe.ch> <20090209134738.G15166@treehorn.dfmm.org> <86eiy5nqjz.fsf@ds4.des.no> <20090211122200.GA86644@hobbes.ustdmz.roe.ch> <86skmlm6aa.fsf@ds4.des.no> Message-ID: <74704C56-60C9-4074-900E-15CFA735B840@tcbug.org> On Feb 11, 2009, at 7:50 AM, Dag-Erling Sm?rgrav wrote: > Daniel Roethlisberger writes: >> Your statement is of course correct, logging in from untrusted >> machines can never be secure. However, OPIE still raises the bar >> on the required capabilities for an attack (active, real-time >> attack versus passive keylogging / data dumping). > > This conversation reminds me of a flipchart outside the terminal > room at > an early BSDCon, with a list of passwords sniffed from the network and > something like "if your password is listed below, you should consider > using SSH" :) > > DES > -- > Dag-Erling Sm?rgrav - des@des.no This conversation reminds me of: http://xkcd.com/538/ Thanks, Josh Paetzel From cperciva at freebsd.org Sun Feb 15 06:56:02 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Sun Feb 15 06:56:09 2009 Subject: HEADS UP: telnetd exploit in the wild, advisory coming soon Message-ID: <49982CB1.5040502@freebsd.org> Hi all, A semi-remote root exploit for telnetd was posted to the full-disclosure list yesterday: http://lists.grok.org.uk/pipermail/full-disclosure/2009-February/067954.html Because the FreeBSD security team didn't get any advance notice of this, we're still investigating and don't have an official advisory or patches ready yet; we're working on it. Some basic information from our investigation so far, subject to change as we investigate further: * this affects telnetd in FreeBSD 7.0-RELEASE, 7.1-RELEASE, 7-STABLE, and 8-CURRENT. * telnetd is disabled by default; if it is enabled, this is normally done via inetd(8). * dragonflybsd is vulnerable to this exploit, but for a completely different reason. Don't try to use their patch -- it won't work. * in order to exploit this, an attacker needs to put a file somewhere on the vulnerable system with a known path. For an attacker who already has non-root access, this is obviously trivial; for an attacker without an account it may be possible to do this by sending an email to a user on the system, exploiting a CGI script, uploading a file via anonymous FTP, etc. I strongly recommend disabling telnetd on all FreeBSD 7.x and 8.x systems. Check that telnetd isn't running (`ps ax | grep telnetd | grep -v grep` should return nothing) and that it isn't enabled in inetd.conf (`grep telnetd /etc/inetd.conf | grep -v ^#` should return nothing). If you absolutely must run telnetd, use a firewall to restrict access to people whom you trust with root access. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From security-advisories at freebsd.org Mon Feb 16 14:02:34 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Mon Feb 16 14:02:47 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:05.telnetd Message-ID: <200902162202.n1GM2X4L003825@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:05.telnetd Security Advisory The FreeBSD Project Topic: telnetd code execution vulnerability Category: core Module: contrib Announced: 2009-02-16 Affects: FreeBSD 7.x Corrected: 2009-02-16 21:56:17 UTC (RELENG_7, 7.1-STABLE) 2009-02-16 21:56:17 UTC (RELENG_7_1, 7.1-RELEASE-p10) 2009-02-16 21:56:17 UTC (RELENG_7_0, 7.0-RELEASE-p3) For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The FreeBSD telnet daemon, telnetd(8), implements the server side of the TELNET virtual terminal protocol. It has been disabled by default in FreeBSD since August 2001, and due to the lack of cryptographic security in the TELNET protocol, it is strongly recommended that the SSH protocol be used instead. The FreeBSD telnet daemon can be enabled via the /etc/inetd.conf configuration file and the inetd(8) daemon. The TELNET protocol allows a connecting client to specify environment variables which should be set in any created login session; this is used, for example, to specify terminal settings. II. Problem Description In order to prevent environment variable based attacks, telnetd(8) "scrubs" its environment; however, recent changes in FreeBSD's environment-handling code rendered telnetd's scrubbing inoperative, thereby allowing potentially harmful environment variables to be set. III. Impact An attacker who can place a specially-constructed file onto a target system (either by legitimately logging into the system or by exploiting some other service on the system) can execute arbitrary code with the privileges of the user running the telnet daemon (usually root). IV. Workaround No workaround is available, but systems which are not running the telnet daemon are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE, or to the RELENG_7_1 or RELENG_7_0 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 7.0 and 7.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-09:05/telnetd.patch # fetch http://security.FreeBSD.org/patches/SA-09:05/telnetd.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/lib/libtelnet # make obj && make depend && make # cd /usr/src/libexec/telnetd # make obj && make depend && make && make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_7 src/contrib/telnet/telnetd/sys_term.c 1.18.22.1 RELENG_7_1 src/UPDATING 1.507.2.13.2.6 src/sys/conf/newvers.sh 1.72.2.9.2.7 src/contrib/telnet/telnetd/sys_term.c 1.18.30.2 RELENG_7_0 src/UPDATING 1.507.2.3.2.14 src/sys/conf/newvers.sh 1.72.2.5.2.14 src/contrib/telnet/telnetd/sys_term.c 1.18.26.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/7/ r188699 releng/7.1/ r188699 releng/7.0/ r188699 - ------------------------------------------------------------------------- VII. References http://lists.grok.org.uk/pipermail/full-disclosure/2009-February/067954.html The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:05.telnetd.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmZ4dwACgkQFdaIBMps37JI2gCfZsCqw/ev/qVKELwNiFxj8zra aooAn0GU4wBW7jBulFhrSyXtKVlgs18B =joA6 -----END PGP SIGNATURE----- From Alexander at Leidinger.net Tue Feb 17 02:20:38 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Feb 17 04:28:24 2009 Subject: OPIE considered insecure In-Reply-To: <200902121113.58828.mail@maxlor.com> References: <200902090957.27318.mail@maxlor.com> <200902111821.53437.mail@maxlor.com> <20090212104119.45583e6fcp63gcmc@webmail.leidinger.net> <200902121113.58828.mail@maxlor.com> Message-ID: <20090217112021.140370oxweabeacc@webmail.leidinger.net> Quoting Benjamin Lutz (from Thu, 12 Feb 2009 11:13:58 +0100): > Hi Alexander, Sorry for the delay, an illness is making its rounds here and I got hit too... > On Thursday 12 February 2009 10:41:19 Alexander Leidinger wrote: >> - Implement something which is similar o freeauth.org, just better >> implemented and without the "not so good" stuff / design decissions. >> >> Short: they need something you know (PIN) + something you have (e.g. >> token, or mobile phone with java with some fixed key). You then enter >> your arbitrary long PIN into the phone, and it will give you a time >> limited key to login (so the time needs to be in sync to some extend). >> On the machine you login you need the cleartext version of your PIN, >> the fixed key, and ideally it saves the the PW you just used to login >> to prevent a relogin with the same PW. If you've seen the remote login >> tokens from RSA or similar, then you should get the idea what this is >> about. > > I've stumbled accross freeauth.org while researching the subject. The reason > I didn't consider it is because so far I've been just printing out my otps, > and that's no longer possible with freeauth.org. And there are situations > where I can't run a Java program on my phone, for example when I'm using > the phone as a bluetooth modem. Nothing prevents you to write a program in C, perl, or whatever. This way you can generate the PW on the system where you use the blutooth modem (in case it is trusted). > I'm not saying that time-based pws wouldn't be nice to have, it just goes in > a different direction than OPIE, so it's not what I'm looking for at the > moment. Also, the thought of having to write programs in J2ME again > horrifies me :) > >> I wrote down a while ago the algorithm somewhere (based upon my own >> thoughts how to do it, this was before I've seen freeauth, so it's >> independent), and also thought about the bells and whistles (some >> security pitfalls you need to think about). If you are interested in >> implementing this (ideally with a BSD license for inclusion into the >> base system) > > While I most probably won't implement freeauth.org, I'd still like to see > your notes; the security pitfalls you considered are likely there for other > algorithms too. The notes are in the direction of notifying the user if the PIN can hit non-volatile storage, or that the storage area of the PIN needs to 0ed in-place after use to prevent it to appear in (provoked) crash dumps or just plain reading from memory. There are also notes about the valid character set (there should be no NUL byte or newline, but apart from that there should be not much restrictions (depends upon the device you use to enter the PIN)), that the device which prints out the PW should also have an indication for the lifetime of the PW, that the server should save the valid PWs of the current valid timeframe to prevent multiple logins with the same PW (also serves as an indicator that someone spied out the PW in case you enter the PW correctly and the timeframe is OK too). The algorithm itself is not 100% finished yet. The generic part is done, but I haven't finished the details (important here is the format of the date which is passed to the hash function, which hash funtion to use, how long the PW can be (truncation of the hash and the corresponding security implications... also in the light of user convenience)). If someone really wants to put some amount of time/work into this, I can put it up on the FreeBSD wiki and hand out contributor access to it, but just to satisfy the curiosity of people, I'm not interested to invest the necessary time to polish it and put it up on the wiki. Bye, Alexander. -- A sect or party is an elegant incognito devised to save a man from the vexation of thinking. -- Ralph Waldo Emerson, Journals, 1831 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From tom at tomjudge.com Tue Feb 17 11:08:34 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Feb 17 11:08:49 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:05.telnetd In-Reply-To: <200902162202.n1GM2XUX003834@freefall.freebsd.org> References: <200902162202.n1GM2XUX003834@freefall.freebsd.org> Message-ID: <499B06ED.6030900@tomjudge.com> Hi, It seems that you got the patch levels wrong in this announcement, should it not be: 2009-02-16 21:56:17 UTC (RELENG_7, 7.1-STABLE) 2009-02-16 21:56:17 UTC (RELENG_7_1, 7.1-RELEASE-p3) 2009-02-16 21:56:17 UTC (RELENG_7_0, 7.0-RELEASE-p10) Rather than: 2009-02-16 21:56:17 UTC (RELENG_7, 7.1-STABLE) 2009-02-16 21:56:17 UTC (RELENG_7_1, 7.1-RELEASE-p10) 2009-02-16 21:56:17 UTC (RELENG_7_0, 7.0-RELEASE-p3) Regards Tom Judge FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ============================================================================= > FreeBSD-SA-09:05.telnetd Security Advisory > The FreeBSD Project > > Topic: telnetd code execution vulnerability > > Category: core > Module: contrib > Announced: 2009-02-16 > Affects: FreeBSD 7.x > Corrected: 2009-02-16 21:56:17 UTC (RELENG_7, 7.1-STABLE) > 2009-02-16 21:56:17 UTC (RELENG_7_1, 7.1-RELEASE-p10) > 2009-02-16 21:56:17 UTC (RELENG_7_0, 7.0-RELEASE-p3) > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > The FreeBSD telnet daemon, telnetd(8), implements the server side of the > TELNET virtual terminal protocol. It has been disabled by default in > FreeBSD since August 2001, and due to the lack of cryptographic security > in the TELNET protocol, it is strongly recommended that the SSH protocol > be used instead. The FreeBSD telnet daemon can be enabled via the > /etc/inetd.conf configuration file and the inetd(8) daemon. > > The TELNET protocol allows a connecting client to specify environment > variables which should be set in any created login session; this is used, > for example, to specify terminal settings. > > II. Problem Description > > In order to prevent environment variable based attacks, telnetd(8) "scrubs" > its environment; however, recent changes in FreeBSD's environment-handling > code rendered telnetd's scrubbing inoperative, thereby allowing potentially > harmful environment variables to be set. > > III. Impact > > An attacker who can place a specially-constructed file onto a target system > (either by legitimately logging into the system or by exploiting some other > service on the system) can execute arbitrary code with the privileges of > the user running the telnet daemon (usually root). > > IV. Workaround > > No workaround is available, but systems which are not running the telnet > daemon are not vulnerable. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to 7-STABLE, or to the RELENG_7_1 or > RELENG_7_0 security branch dated after the correction date. > > 2) To patch your present system: > > The following patches have been verified to apply to FreeBSD 7.0 and 7.1 > systems. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-09:05/telnetd.patch > # fetch http://security.FreeBSD.org/patches/SA-09:05/telnetd.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # cd /usr/src/lib/libtelnet > # make obj && make depend && make > # cd /usr/src/libexec/telnetd > # make obj && make depend && make && make install > > VI. Correction details > > The following list contains the revision numbers of each file that was > corrected in FreeBSD. > > CVS: > > Branch Revision > Path > - ------------------------------------------------------------------------- > RELENG_7 > src/contrib/telnet/telnetd/sys_term.c 1.18.22.1 > RELENG_7_1 > src/UPDATING 1.507.2.13.2.6 > src/sys/conf/newvers.sh 1.72.2.9.2.7 > src/contrib/telnet/telnetd/sys_term.c 1.18.30.2 > RELENG_7_0 > src/UPDATING 1.507.2.3.2.14 > src/sys/conf/newvers.sh 1.72.2.5.2.14 > src/contrib/telnet/telnetd/sys_term.c 1.18.26.1 > - ------------------------------------------------------------------------- > > Subversion: > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/7/ r188699 > releng/7.1/ r188699 > releng/7.0/ r188699 > - ------------------------------------------------------------------------- > > VII. References > > http://lists.grok.org.uk/pipermail/full-disclosure/2009-February/067954.html > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-09:05.telnetd.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (FreeBSD) > > iEYEARECAAYFAkmZ4dwACgkQFdaIBMps37JI2gCfZsCqw/ev/qVKELwNiFxj8zra > aooAn0GU4wBW7jBulFhrSyXtKVlgs18B > =joA6 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org" > From axel.scheepers at nl.clara.net Tue Feb 17 11:34:02 2009 From: axel.scheepers at nl.clara.net (Axel Scheepers) Date: Tue Feb 17 11:50:55 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:05.telnetd In-Reply-To: <499B06ED.6030900@tomjudge.com> References: <200902162202.n1GM2XUX003834@freefall.freebsd.org> <499B06ED.6030900@tomjudge.com> Message-ID: <1234898594.7722.32.camel@ceridwen.thuis.net> On Tue, 2009-02-17 at 12:50 -0600, Tom Judge wrote: > Hi, > > It seems that you got the patch levels wrong in this announcement, should it not be: Yep, I was wondering (and checked out to verify/build) also. Kind regards, Axel Scheepers From krassi at bulinfo.net Mon Feb 23 06:44:24 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Feb 23 06:44:40 2009 Subject: OpenSolaris Cryptographic Framework Message-ID: <49A2B244.3000307@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello All, Is there any plans to import the Cryptographic Framework from OpenSolaris to FreeBSD? Reference: http://opensolaris.org/os/project/crypto/ Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJorJExJBWvpalMpkRAvrwAJ9Aljih91ZGrH5PyiDmQq0emMVIswCeKRJG A4tkeKHLNToe479kr8p2CbM= =ys/e -----END PGP SIGNATURE----- From ivangrvr299 at gmail.com Tue Feb 24 08:06:53 2009 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Tue Feb 24 08:07:00 2009 Subject: PAM rules inside pam.d Message-ID: <670f29e20902240717m49f53bfx67166c151c01384b@mail.gmail.com> Hi All, I had PAM rules for my own service as below: auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_deny.so This used to work properly in my older PAM libraries. For successfull authentication, it used to return from pam_stack.so as system-auth has sufficient in its rules as below and it doesnt pass below the stack to pam_deny.so auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so Now, after upgrading PAM modules (pam_unix.so, pam_stack.so..) and library, It doesnt work, To make it work, I need to remove the last one, pam_deny.so as below. auth required pam_stack.so service=system-auth auth required pam_nologin.so Can any one please let me know if you have seen similar problem. Any suggestions/comments, please advice. From des at des.no Tue Feb 24 11:41:40 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Feb 24 11:41:54 2009 Subject: PAM rules inside pam.d In-Reply-To: <670f29e20902240717m49f53bfx67166c151c01384b@mail.gmail.com> (Ivan Grover's message of "Tue, 24 Feb 2009 20:47:00 +0530") References: <670f29e20902240717m49f53bfx67166c151c01384b@mail.gmail.com> Message-ID: <86eixnfwr2.fsf@ds4.des.no> Ivan Grover writes: > Now, after upgrading PAM modules (pam_unix.so, pam_stack.so..) and > library [...] Upgrading from what to what? Have you tried the standard debugging procedure? DES -- Dag-Erling Sm?rgrav - des@des.no From ivangrvr299 at gmail.com Fri Feb 27 06:18:43 2009 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Fri Feb 27 06:18:55 2009 Subject: PAM rules inside pam.d In-Reply-To: <86eixnfwr2.fsf@ds4.des.no> References: <670f29e20902240717m49f53bfx67166c151c01384b@mail.gmail.com> <86eixnfwr2.fsf@ds4.des.no> Message-ID: <670f29e20902270618m23eed4acg15a8a3e7b43fe327@mail.gmail.com> Hi, Iam sorry my observation was wrong. I debugged the problem, it looks strange, these are my findings : I have my PAM rules for my service as auth required /lib/security/pam_securetty.so auth required pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so The pam_unix module returns authentication failure from pam_unix.so from pam_stack.so , hence the control reaches pam_nologin.so. The same rules work well with telnet/ftp , but fails for my service I have checked the username, password passed to PAM module by changing the sources of pam_nologin.so, they are proper. I didnt had sources for pam_unix, so iam not able to detect the exact problem. My suspect is that my application using my PAM service might have done some fd leaks or any other problem. But the max fds open by my application are 185 which is still below max limit(OPEN_MAX) Restarting the application resolves the problem and iam able to authenticate user can anyone help me what could be the problem. Thanks and Best Regards, On Wed, Feb 25, 2009 at 1:11 AM, Dag-Erling Sm?rgrav wrote: > Ivan Grover writes: > > Now, after upgrading PAM modules (pam_unix.so, pam_stack.so..) and > > library [...] > > Upgrading from what to what? > > Have you tried the standard debugging procedure? > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From ivangrvr299 at gmail.com Fri Feb 27 08:10:44 2009 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Fri Feb 27 08:10:50 2009 Subject: PAM rules inside pam.d In-Reply-To: <670f29e20902270618m23eed4acg15a8a3e7b43fe327@mail.gmail.com> References: <670f29e20902240717m49f53bfx67166c151c01384b@mail.gmail.com> <86eixnfwr2.fsf@ds4.des.no> <670f29e20902270618m23eed4acg15a8a3e7b43fe327@mail.gmail.com> Message-ID: <670f29e20902270810h22adc102rd9500d74208b1f11@mail.gmail.com> I debugged pam_unix aswell, it looks like crypt function is giving different strings for telnet and my application with same passwd string and salt. So i think the issue could be with crypt library linked telnet and my application. please let me know your thoughts crypt(plaintext_ptr, salt); On Fri, Feb 27, 2009 at 7:48 PM, Ivan Grover wrote: > Hi, > Iam sorry my observation was wrong. > > I debugged the problem, it looks strange, these are my findings : > > I have my PAM rules for my service as > > auth required /lib/security/pam_securetty.so > auth required pam_stack.so service=system-auth > auth required /lib/security/pam_nologin.so > > The pam_unix module returns authentication failure from pam_unix.so from > pam_stack.so , hence the control reaches pam_nologin.so. > > The same rules work well with telnet/ftp , but fails for my service > > I have checked the username, password passed to PAM module by changing the > sources of pam_nologin.so, they are proper. I didnt had sources for > pam_unix, so iam not able to detect the exact problem. > > My suspect is that my application using my PAM service might have done some > fd leaks or any other problem. But the max fds open by my application are > 185 which is still below max limit(OPEN_MAX) > > Restarting the application resolves the problem and iam able to > authenticate user > > > can anyone help me what could be the problem. > > > Thanks and Best Regards, > > > > On Wed, Feb 25, 2009 at 1:11 AM, Dag-Erling Sm?rgrav wrote: > >> Ivan Grover writes: >> > Now, after upgrading PAM modules (pam_unix.so, pam_stack.so..) and >> > library [...] >> >> Upgrading from what to what? >> >> Have you tried the standard debugging procedure? >> >> DES >> -- >> Dag-Erling Sm?rgrav - des@des.no >> > >