Re: Security in a shell that starts ssh
That would probably work, but for style I'd use 'break;' instead of 'i=100;'.
You also don't need to be quite so paranoid with printf, it's generally safe
unless you are printf'ing data entered by the user. If it's all your own
text, they can't insert anything strange into it...
Also, instead of the read() loop, I think you should check out the man page
for fgets(). That will probably suit your needs better.
I'm sure others have other ideas on it...
On Tue, 12 Jun 2001, Miquel Mart?n L?pez wrote:
> Hi all!
> We have several vt-100 terminal that log to the naub server at our office.
> Still, some users without account in the main server would like to login to
> another machine, so I was planning on creating a passwordless acount with a
> shell that's a program that asks for usernames and then execs ssh -l
> username. I didn't want to do a script to avouid ppl hitting ctrl+c and
> having a passwordless account. I'm also worried about buffer-overflows and a
> miriad things I'm too newbie to understand, so I'd appreciate any comments
> on the security flaws you see on this:
>
> #include
>
> main(){
> int i=0;
> char name[10];
>
> write(1,"Login as: ",10);
>
> while(i<10)
> {
> read(0,&name[i],1);
> if (name[i]=='\n') {name[i]='\0';i=100;}
> i++;
> }
> execlp("/usr/bin/ssh","ssh","foo.foo.es","-l",name,(char *)0);
> }
>
>
> Any advice welcome! :)
> Miquel Mart?n
Re: Security in a shell that starts ssh
That would probably work, but for style I'd use 'break;' instead of 'i=100;'.
You also don't need to be quite so paranoid with printf, it's generally safe
unless you are printf'ing data entered by the user. If it's all your own
text, they can't insert anything strange into it...
Also, instead of the read() loop, I think you should check out the man page
for fgets(). That will probably suit your needs better.
I'm sure others have other ideas on it...
On Tue, 12 Jun 2001, Miquel Mart?n L?pez wrote:
> Hi all!
> We have several vt-100 terminal that log to the naub server at our office.
> Still, some users without account in the main server would like to login to
> another machine, so I was planning on creating a passwordless acount with a
> shell that's a program that asks for usernames and then execs ssh -l
> username. I didn't want to do a script to avouid ppl hitting ctrl+c and
> having a passwordless account. I'm also worried about buffer-overflows and a
> miriad things I'm too newbie to understand, so I'd appreciate any comments
> on the security flaws you see on this:
>
> #include
>
> main(){
> int i=0;
> char name[10];
>
> write(1,"Login as: ",10);
>
> while(i<10)
> {
> read(0,&name[i],1);
> if (name[i]=='\n') {name[i]='\0';i=100;}
> i++;
> }
> execlp("/usr/bin/ssh","ssh","foo.foo.es","-l",name,(char *)0);
> }
>
>
> Any advice welcome! :)
> Miquel MartÃn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
Having a crypto install option (even if it's a little more complex to get) is still better than not having one. At this point, all one can do is encrypt a filesystem off of a non- encrypted root partition. Like removable media or something else that is mounted by hand. There are some logistical problems with doing that for a root filesystem, but those can probably be worked out. Does anyone know of a good cypherpunks list/site? Aaron On Wed, 30 May 2001, Hubert Chan wrote: > Don't forget those countries where the use of cryptography at all is > illegal. > > If Debian were to implement a cryptography-by-default install, it would > also need a non-cryptographic install. The cryptographic install would > also only be avaiable via non-US and its mirrors due to export > restrictions in certain countries. > > Hubert.
Re: root fs/crypted
Having a crypto install option (even if it's a little more complex to get) is still better than not having one. At this point, all one can do is encrypt a filesystem off of a non- encrypted root partition. Like removable media or something else that is mounted by hand. There are some logistical problems with doing that for a root filesystem, but those can probably be worked out. Does anyone know of a good cypherpunks list/site? Aaron On Wed, 30 May 2001, Hubert Chan wrote: > Don't forget those countries where the use of cryptography at all is > illegal. > > If Debian were to implement a cryptography-by-default install, it would > also need a non-cryptographic install. The cryptographic install would > also only be avaiable via non-US and its mirrors due to export > restrictions in certain countries. > > Hubert. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel: NAT: 0 dropping untracked packet c1aa2300 1 10.20.30.132 -> 62.142.131.12
I assume that is on the ethernet side facing the ISP? Or that you have one ethernet card and all traffic is going there? Cable modem? (read: shared media) My bet would be that someone else is doing NAT as well, and you are seeing their packets too (probably because they are using only one card as well), but your box doesn't know about their NATd box, so it complains. You could add a rule to PREROUTING that drops anything from 10/8 that you aren't using, then you probably wouldn't see those messages anymore. Aaron On Sat, 31 Mar 2001, Martin Fluch wrote: > Hello, > > I have the following problem. A few days before I compiled my 2.4.2 kernel > with support for NAT in order to get a computer of a friend of mine > connected to the internet (we had to masquerade his computer since my ISP > has fixed the internet connection to the MAC address of my network card, > but that's an other story). The whole thing went ok, but there is one > thing which puzzles me. > > >From the begining I got ever once in a while a message of the following > type in my logs: > > Mar 31 13:50:17 seneca kernel: NAT: 0 dropping untracked packet c1ecc980 1 > 10.20.30.132 -> 62.142.131.12 > > Ok, that might happen I thought (and I am anything else but a expert in > this NAT stuff, so I realy don't know, what this message means, but as > long as it happend only seldom I didn't care much about it). But yesterday > the appareance of these messages started to increase and today its realy > anoying. So I'm realy wondering, what's going on here? Especialy offten > the source address 10.20.30.132 is mentioned, once in a while (but > seldom) there are other addresses outside the local network, for example > 169.254.27.17 (About my network: My IP is 62.142.131.26, the gateway is > 62.142.131.1) > > I've attached the gnuziped part of kern.log from the last reboot on (45 > min containing about 300 messages). Perhaps somebody has a clue, what is > going on here in the network? > > Thank you in advance, > Martin >
Re: kernel: NAT: 0 dropping untracked packet c1aa2300 1 10.20.30.132-> 62.142.131.12
I assume that is on the ethernet side facing the ISP? Or that you have one ethernet card and all traffic is going there? Cable modem? (read: shared media) My bet would be that someone else is doing NAT as well, and you are seeing their packets too (probably because they are using only one card as well), but your box doesn't know about their NATd box, so it complains. You could add a rule to PREROUTING that drops anything from 10/8 that you aren't using, then you probably wouldn't see those messages anymore. Aaron On Sat, 31 Mar 2001, Martin Fluch wrote: > Hello, > > I have the following problem. A few days before I compiled my 2.4.2 kernel > with support for NAT in order to get a computer of a friend of mine > connected to the internet (we had to masquerade his computer since my ISP > has fixed the internet connection to the MAC address of my network card, > but that's an other story). The whole thing went ok, but there is one > thing which puzzles me. > > >From the begining I got ever once in a while a message of the following > type in my logs: > > Mar 31 13:50:17 seneca kernel: NAT: 0 dropping untracked packet c1ecc980 1 > 10.20.30.132 -> 62.142.131.12 > > Ok, that might happen I thought (and I am anything else but a expert in > this NAT stuff, so I realy don't know, what this message means, but as > long as it happend only seldom I didn't care much about it). But yesterday > the appareance of these messages started to increase and today its realy > anoying. So I'm realy wondering, what's going on here? Especialy offten > the source address 10.20.30.132 is mentioned, once in a while (but > seldom) there are other addresses outside the local network, for example > 169.254.27.17 (About my network: My IP is 62.142.131.26, the gateway is > 62.142.131.1) > > I've attached the gnuziped part of kern.log from the last reboot on (45 > min containing about 300 messages). Perhaps somebody has a clue, what is > going on here in the network? > > Thank you in advance, > Martin > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Woody ssh exploit
On Thu, 22 Feb 2001, Peter Cordes wrote: > On Thu, Feb 22, 2001 at 11:10:39AM -0800, Micah Anderson wrote: > > We are currently running woody on a production machine (yes, I am not that > > happy about that decision). Woody does not get potato's security updates, > > and does not get new unstable security fixes in a timely fashion. This > > leaves woody vulnerable to certain kinds of problems, particularly > > distressing right now is the ssh security issue that is out there, which > > woody does not have a fix for. Potato has a fix at > > http://www.debian.org/security/2001/dsa-027 > > > > So how do we fix this on a woody machine? > > I installed ssh 2.3.0p1-1.11 from unstable on my woody machines at home. > It works great. Yes, but 2.4.0 is current.
Re: Woody ssh exploit
You could just recompile it yourself. I don't even use any of the Debian SSH packages anymore, they are mostly out-of-date anyway. The current SSH2 in woody is 2.0.13, for example. I just download the source and compile it myself for those kind of things. There's another good point to that: Anything that intimitely connected with your system security should be done by hand anyway. Actually, if someone wants to give me a hint on how to use the dpkg tool to build things (never done it before!) and how to upload the compiled versions, I'd re-contribute the packages. Aaron On Thu, 22 Feb 2001, Micah Anderson wrote: > We are currently running woody on a production machine (yes, I am not that > happy about that decision). Woody does not get potato's security updates, > and does not get new unstable security fixes in a timely fashion. This > leaves woody vulnerable to certain kinds of problems, particularly > distressing right now is the ssh security issue that is out there, which > woody does not have a fix for. Potato has a fix at > http://www.debian.org/security/2001/dsa-027 > > So how do we fix this on a woody machine? > > There are a few things that can be done, none of them very great. There is > the possibility of putting the potato package on our machine, but are there > are dependancy issues or problems downgrading a package from woody to > potato? What about when a fix does finally come available for woody, will it > be an issue to bring the potato package up to that woody upgrade? There is > the possibility of enabling protocol2 only on our ssh installation, which > would make us safe, but is only an interim fix until an update comes > available for woody, this an issue for people who cannot connect via > protocol 2, and an annoyance/education effort for those who connect via > protocol 1. > > All of these aren't great. Unless I am wrong, currently there is no known > exploit for this hole, but that isn't that much of a reassurance either. > > Thanks, > Micah
Re: Woody ssh exploit
On Thu, 22 Feb 2001, Peter Cordes wrote: > On Thu, Feb 22, 2001 at 11:10:39AM -0800, Micah Anderson wrote: > > We are currently running woody on a production machine (yes, I am not that > > happy about that decision). Woody does not get potato's security updates, > > and does not get new unstable security fixes in a timely fashion. This > > leaves woody vulnerable to certain kinds of problems, particularly > > distressing right now is the ssh security issue that is out there, which > > woody does not have a fix for. Potato has a fix at > > http://www.debian.org/security/2001/dsa-027 > > > > So how do we fix this on a woody machine? > > I installed ssh 2.3.0p1-1.11 from unstable on my woody machines at home. > It works great. Yes, but 2.4.0 is current. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Woody ssh exploit
You could just recompile it yourself. I don't even use any of the Debian SSH packages anymore, they are mostly out-of-date anyway. The current SSH2 in woody is 2.0.13, for example. I just download the source and compile it myself for those kind of things. There's another good point to that: Anything that intimitely connected with your system security should be done by hand anyway. Actually, if someone wants to give me a hint on how to use the dpkg tool to build things (never done it before!) and how to upload the compiled versions, I'd re-contribute the packages. Aaron On Thu, 22 Feb 2001, Micah Anderson wrote: > We are currently running woody on a production machine (yes, I am not that > happy about that decision). Woody does not get potato's security updates, > and does not get new unstable security fixes in a timely fashion. This > leaves woody vulnerable to certain kinds of problems, particularly > distressing right now is the ssh security issue that is out there, which > woody does not have a fix for. Potato has a fix at > http://www.debian.org/security/2001/dsa-027 > > So how do we fix this on a woody machine? > > There are a few things that can be done, none of them very great. There is > the possibility of putting the potato package on our machine, but are there > are dependancy issues or problems downgrading a package from woody to > potato? What about when a fix does finally come available for woody, will it > be an issue to bring the potato package up to that woody upgrade? There is > the possibility of enabling protocol2 only on our ssh installation, which > would make us safe, but is only an interim fix until an update comes > available for woody, this an issue for people who cannot connect via > protocol 2, and an annoyance/education effort for those who connect via > protocol 1. > > All of these aren't great. Unless I am wrong, currently there is no known > exploit for this hole, but that isn't that much of a reassurance either. > > Thanks, > Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: who owns the ports?
Well, finger is probably running through inetd... Either that or you are running that scanner detecter package that binds to every port known in the universe. Aaron On Wed, 7 Feb 2001, Matthias G. Imhof wrote: > Performing strobe or nmap on my system, I get, e.g., the following list: > > 79/tcp openfinger > 119/tcpopennntp > 143/tcpopenimap2 > 540/tcpopenuucp > 6667/tcp openirc > 12345/tcp openNetBus > 12346/tcp openNetBus > 31337/tcp openElite > > However, lsof -i tcp:79 yields nothing. Similarly with the others. > In addition, there should be no irc running, finger is commented from the > inetd.conf, and so on. > > Why do these ports respond to strobe or nmap? Which process controlls them? > > Matthias
Re: who owns the ports?
Well, finger is probably running through inetd... Either that or you are running that scanner detecter package that binds to every port known in the universe. Aaron On Wed, 7 Feb 2001, Matthias G. Imhof wrote: > Performing strobe or nmap on my system, I get, e.g., the following list: > > 79/tcp openfinger > 119/tcpopennntp > 143/tcpopenimap2 > 540/tcpopenuucp > 6667/tcp openirc > 12345/tcp openNetBus > 12346/tcp openNetBus > 31337/tcp openElite > > However, lsof -i tcp:79 yields nothing. Similarly with the others. > In addition, there should be no irc running, finger is commented from the > inetd.conf, and so on. > > Why do these ports respond to strobe or nmap? Which process controlls them? > > Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: your mail
Yes, the best policy is always to disable anything on your machine that you're not using. Those you _are_ using, you then filter the crap out of. Personally, my workstation-type machines only listen on port 6000 (X), 22 (ssh), and occasionally ftp and tftp if I need them for a specific purpose. For my server-type machines, subtract X, then add what services they are providing, which would then be heavily protected. On Thu, 16 Mar 2000, Peter Cordes wrote: > This isn't specific to identd, but I'm wondering why you would bother > filtering the port instead of just not running identd? (I assume you would > have/do turn off identd in /etc/inetd.conf as well as using doing port > filtering.) I've never really understood why people filter all kinds of > ports on their own machine when the ports are closed anyway. The only > advantage I can see is that if someone hits you with a trojan > something-or-other, the the bad guys won't be able to talk to it if it picks > a blocked port. Is this the reason for doing it, or am I missing something? > > Filtering ports makes sense when you are protecting a bunch of machines, > especially ones which you don't run directly, but for a machine filtering > traffic for only itself, it seems like a waste. > > Thanks,
