Re: AW: security issue: tomcat on port 80
Ok, this subject is getting pretty far from Tomcat, but I'll address this. I asked once on the OpenBSD list. Those guys are very much traditionalists so they did not like the idea. Still, there is no longer any rational reason for this restriction. I challenge anyone to point out a good reason for it. Basically, it I discussed this on a local LUG. It seems there are plenty of local root exploits and even if u run the servers as non-root, you can still gain access to this non-root user and then use the local root exploits to get root. Now how do u beat this ? Yes, there are plenty of local root exploits in Linux. There has even been one in OpenBSD. Local root exploits are a fact of life in non-trusted systems such as OpenBSD and Linux. In your post you sugest that if I were running the web server as non-root, and it had a buffer overflow or similar vulnerability, the hack process would be this: 1. Hack into web server process. 2. Run local - root exploit. 3. Done. In the case where the server is running as root (which is the case on all *UNIX things right now), the process looks like this: 1. Hack into web server process. 2. Done. Your comment above basicly proves my point that we get better security if we allow non-root stuff to bind to low ports. The reason why this is such a big deal is that Step 2 (Run local - root exploit) is an extra barrier and it can be very very difficult barrier on some OSes, such as OpenBSD or a well-configured Linux system. In its years of existence, OpenBSD has had only one local - root exploit. On the subject of local - root exploits, they are mostly caused by SUID processes, like sendmail or trivial things like lpd or at. If you want your server to be secure, audit the system for suid files and turn off all that aren't absolutely necessary. This goes a long way. Btw, there would be a lot _less_ suid stuff on systems if non-root could bind to low ports. This would also prevent some local attacks. Basically security design is hard to understand and few people understand it. People who don't understand it often think that more restrictions means more secure, which is often incorrect, because it often means that you need to run ordinary stuff at higher permission levels to get around these restrictions, and that's bad. People who understand security design think more in terms of comparentalization and auditing than in terms of generic restrictions. Trusted systems like EROS, Trusted BSD and SE Linux are based on this idea. Root is the root of all evil, and so these three systems solve the problem by not having root. This may sound strange, but that actually makes the systems _easier_ to use. Just for completeness, here is how the above attack would look on a Trusted BSD system: 1. Hack into web server process. 2. Serve your own | 0\^//\/ 7H|S S|73!! message. 3. That's all you can do. Oh, and it's all audited. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: security issue: tomcat on port 80
I asked once on the OpenBSD list. Those guys are very much traditionalists so they did not like the idea. Still, there is no longer any rational reason for this restriction. I challenge anyone to point out a good reason for it. Basically, it I discussed this on a local LUG. It seems there are plenty of local root exploits and even if u run the servers as non-root, you can still gain access to this non-root user and then use the local root exploits to get root. Now how do u beat this ? used to be the case that sysadmins didn't want ordinary users to be able to run sendmail on port 25. This altruisticly protects other users on other machines from dealing with trojaned services (ie, trojan telnetd, etc). This concern is ridiculous today, because how often do you telnet to some unknown server and enter a password? Never, probably. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: security issue: tomcat on port 80
Have you tried asking your question in the linux mailing lists ? What do those guys got to say about this restriction to bind to ports 1024 in the present day server systems? I asked once on the OpenBSD list. Those guys are very much traditionalists so they did not like the idea. Still, there is no longer any rational reason for this restriction. I challenge anyone to point out a good reason for it. Basically, it used to be the case that sysadmins didn't want ordinary users to be able to run sendmail on port 25. This altruisticly protects other users on other machines from dealing with trojaned services (ie, trojan telnetd, etc). This concern is ridiculous today, because how often do you telnet to some unknown server and enter a password? Never, probably. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: security issue: tomcat on port 80
Dr. Evil: Have you tried asking your question in the linux mailing lists ? What do those guys got to say about this restriction to bind to ports 1024 in the present day server systems? --- Dr. Evil [EMAIL PROTECTED] wrote: The VM itself is typically writen in C/C++, so I wouldn't beg on more=20 safety for a VM than Apache. That's probably true. However, the likelihood of someone being able to send a web request to Tomcat that will result in Tomcat triggering a buffer overflow in the VM seems ridiculously small. It's not like the VM is executing arbitrary code from users, even though it is designed to be able to do that safely. And there are other potential risks running tomcat as root. (If you=20 make a configuration or implementation error that allows to store JSP on the server, an intruder can do anything on your server) Yeah, that could be a big problem. This was introduced to protect the ports that are used for the most fundamental services from missuse by any user. Which is plain old stupid, I must say. It's not like Yahoo sells shell accounts on www.yahoo.com, right? It dates from the good old days (now long gone) when root/sysadmins users basically trusted other root users, but didn't trust their own misbehaving shell account users. This is totally irrelevant on today's Internet. In the old days there had to be many users on one machine doing different things because machines were expensive. Machines today are not shared. They are owned and used by single entities, and for server machines (like www.yahoo.com) the only people with access to the machine are ones who already have root access. Either you trust the machine and all of its sysadmins and users, or you don't. How many companies still sell shell account service? This OS limitation no longer has any security upside, and it has a huge downside, which is that the same process which runs CGIs or servlets also has (at some point) the power to edit /etc/passwd, and similar things which it should not have the capability of doing. The ultimate solution for this is capabilities based security. At a very fundamental level, I should be able to give a proc the capability to bind to a port without also giving it the capability to edit /etc/passwd or read arbitrary RAM. The uid 0 to bind 1024 restriction just makes things worse. I'm still waiting for TrustedBSD which will implement all this. Pretty much every exploit known in the Unix world has, as one of its steps, or as its end goal, getting root. The solution to this is to not have root, obviously. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: security issue: tomcat on port 80
The VM itself is typically writen in C/C++, so I wouldn't beg on more=20 safety for a VM than Apache. That's probably true. However, the likelihood of someone being able to send a web request to Tomcat that will result in Tomcat triggering a buffer overflow in the VM seems ridiculously small. It's not like the VM is executing arbitrary code from users, even though it is designed to be able to do that safely. And there are other potential risks running tomcat as root. (If you=20 make a configuration or implementation error that allows to store JSP on the server, an intruder can do anything on your server) Yeah, that could be a big problem. This was introduced to protect the ports that are used for the most fundamental services from missuse by any user. Which is plain old stupid, I must say. It's not like Yahoo sells shell accounts on www.yahoo.com, right? It dates from the good old days (now long gone) when root/sysadmins users basically trusted other root users, but didn't trust their own misbehaving shell account users. This is totally irrelevant on today's Internet. In the old days there had to be many users on one machine doing different things because machines were expensive. Machines today are not shared. They are owned and used by single entities, and for server machines (like www.yahoo.com) the only people with access to the machine are ones who already have root access. Either you trust the machine and all of its sysadmins and users, or you don't. How many companies still sell shell account service? This OS limitation no longer has any security upside, and it has a huge downside, which is that the same process which runs CGIs or servlets also has (at some point) the power to edit /etc/passwd, and similar things which it should not have the capability of doing. The ultimate solution for this is capabilities based security. At a very fundamental level, I should be able to give a proc the capability to bind to a port without also giving it the capability to edit /etc/passwd or read arbitrary RAM. The uid 0 to bind 1024 restriction just makes things worse. I'm still waiting for TrustedBSD which will implement all this. Pretty much every exploit known in the Unix world has, as one of its steps, or as its end goal, getting root. The solution to this is to not have root, obviously. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
AW: AW: security issue: tomcat on port 80
You don't have to sell shell accounts. The past 12 years I worked constantly for companies that had one or more unix servers and always only a small number of users had an admin account, all other had 'normal' user accounts. Even today we share one linux box with several users. (Each user has a Windows Computer at his desk, and uses W-WinPro to access the central development server). And not every body has/knows the the admin account. Even on a single user system I wouldn't recommend to work constantly as administrator (neither under windows nor under linux). I prefer to work always with the least possible rights, so that any virus that might come in, can do fewer harm. (in this sense I don't trust even myself, although I was never infected in all those years) Yes, the solution to this problem is clumsy. Yes, something like service/capability based ACL's for processes would be a better mean to do that. On the other side, I have problems to imagine a solution that is manageable. (unlike the handling of rights under Win2000/Exchange). All the solutions I've seen in the past for trustedxxx, had nice features but where so difficult to configure and maintain, that it was hard to get more security whithout affecting the ease of use for the daily work. -Ursprüngliche Nachricht- Von: Dr. Evil [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 7. Dezember 2001 09:20 An: [EMAIL PROTECTED] Betreff: Re: AW: security issue: tomcat on port 80 snip/ Which is plain old stupid, I must say. It's not like Yahoo sells shell accounts on www.yahoo.com, right? It dates from the good old days (now long gone) when root/sysadmins users basically trusted other root users, but didn't trust their own misbehaving shell account users. This is totally irrelevant on today's Internet. In the old days there had to be many users on one machine doing different things because machines were expensive. Machines today are not shared. They are owned and used by single entities, and for server machines (like www.yahoo.com) the only people with access to the machine are ones who already have root access. Either you trust the machine and all of its sysadmins and users, or you don't. How many companies still sell shell account service? This OS limitation no longer has any security upside, and it has a huge downside, which is that the same process which runs CGIs or servlets also has (at some point) the power to edit /etc/passwd, and similar things which it should not have the capability of doing. The ultimate solution for this is capabilities based security. At a very fundamental level, I should be able to give a proc the capability to bind to a port without also giving it the capability to edit /etc/passwd or read arbitrary RAM. The uid 0 to bind 1024 restriction just makes things worse. I'm still waiting for TrustedBSD which will implement all this. Pretty much every exploit known in the Unix world has, as one of its steps, or as its end goal, getting root. The solution to this is to not have root, obviously. snip/ -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: AW: security issue: tomcat on port 80
The past 12 years I worked constantly for companies that had one or more unix servers and always only a small number of users had an admin=20 account, all other had 'normal' user accounts. Anyway, can someone explain to me the security benefit of restricting bind 1024 to uid 0? At this point I can't see what good it does, and I can see that it does harm. Even on a single user system I wouldn't recommend to work constantly as administrator (neither under=20 windows nor under linux). I prefer to work always with the least possible rights, so that any virus=20 that might come in, can do fewer harm. (in this=20 sense I don't trust even myself, although I was=20 never infected in all those years) No, it's definitely a bad idea to work as root all the time because mistakes can be very bad. I was just explaining why long ago that restriction was implemented. It's ridiculous now. On my server machine, I'm the only one who can log in to it. It would definitely be better if Tomcat could run without uid 0. All the solutions I've seen in the past for trustedxxx, had nice features but where so=20 difficult to configure and maintain, that it was=20 hard to get more security whithout affecting the=20 ease of use for the daily work. I think it's just a question of familiarity. Today when you install Linux/*BSD/etc, all the permissions on all the files are set correctly so you don't have to mess around with it. If you had to figure it all out yourself it would be a pain. Actually the capabilities based stuff may make things easier because today, they try to achieve similar results by having multiple users for multiple stuff (a user for lpd, for uucp, etc) and then use group and file perms. It's a confusing mess. It would be much clearer to say: Sendmail has the capability to bind port 25 and write files in this directory than to figure out the right combination of suid stuff, tcpwrapper, etc, that will do the right thing. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
security issue: tomcat on port 80
How safe is it to have tomcat listening on port 80 running on a RH6.2, which is on the internet ? Did anybody face any security problems ever ? Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: security issue: tomcat on port 80
Hi, There are security implications for running *any* server process on *any* port that is accessible by the public internet. To run a server on UNIX/Linux on a port number of less than 1024 requires root privileges. I would strongly recommend you do *NOT* run Tomcat as the root user since if the server was compromised (by a buffer overflow attack for instance) then the attacker would have root access to the entire machine. I personally run Tomcat behind an Apache web server (which runs on port 80 on a restricted user account) and use mod_webapp to connect the two. Get a book on UNIX system administration and do some web searches, there's plenty of information out there. Hope this helps, Chris -Original Message- From: E B [mailto:[EMAIL PROTECTED]] Sent: 06 December 2001 09:55 To: Tomcat Users List Subject: security issue: tomcat on port 80 How safe is it to have tomcat listening on port 80 running on a RH6.2, which is on the internet ? Did anybody face any security problems ever ? Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: security issue: tomcat on port 80
Java VM actually shields you from buffer overflow attacks, since you cannot overflow an array, let alone do it so that it overwrites code segments. So in case of Tomcat (or any Java-written server), buffer overflow attacks are out of question. Other attacks are still possible, though. Attila. - Original Message - From: Chris Newland [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: 2001. december 6. 12:18 Subject: RE: security issue: tomcat on port 80 Hi, There are security implications for running *any* server process on *any* port that is accessible by the public internet. To run a server on UNIX/Linux on a port number of less than 1024 requires root privileges. I would strongly recommend you do *NOT* run Tomcat as the root user since if the server was compromised (by a buffer overflow attack for instance) then the attacker would have root access to the entire machine. I personally run Tomcat behind an Apache web server (which runs on port 80 on a restricted user account) and use mod_webapp to connect the two. Get a book on UNIX system administration and do some web searches, there's plenty of information out there. Hope this helps, Chris smime.p7s Description: application/pkcs7-signature
Re: security issue: tomcat on port 80
--- Attila Szegedi [EMAIL PROTECTED] wrote: Java VM actually shields you from buffer overflow attacks, since you cannot overflow an array, let alone do it so that it overwrites code segments. So in case of Tomcat (or any Java-written server), buffer overflow attacks are out of question. Other attacks are still possible, though. Can u list some of the other attacks ? Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
AW: security issue: tomcat on port 80
I wouldn't beg on that. Java VM are programs that are implemente in C or C++ or other 'classic' languages. So Bugs introduces here can open the server to overflow attacks. Other problems: With a wrong configuration it may be possible, that a attacker can place a jsp on your server. If the server is running under root he can run any command he likes. With a wrong configration it may be possible that an attacker can read the source of jsp's and see some information that he better not see (This problem is independent from the user the server runs under). -Ursprüngliche Nachricht- Von: Attila Szegedi [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 6. Dezember 2001 12:57 An: Tomcat Users List Betreff: Re: security issue: tomcat on port 80 snip/ Java VM actually shields you from buffer overflow attacks, since you cannot overflow an array, let alone do it so that it overwrites code segments. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: security issue: tomcat on port 80
How safe is it to have tomcat listening on port 80 running on a RH6.2, which is on the internet ? Did anybody face any security problems ever ? From the conventional point of view, having things run on port 80 has been dangerous because a proc has to have uid 0 to bind to the port. Apache is regarded as safe because the code drops root ASAP and si thoroughly tested and audited. Tomcat is not regarded as safe because it can't drop uid 0. However, the reason why uid 0 is so dangerous for Apache is because it's written in C. Buffer overlflows are almost inevitable in a language like C, with its direct memory access and unsafe pointers. Java bytecode doesn't have any of those problems. It can't manipulate memory or pointers ever. It is much much safer than C will ever be. So I think running Tomcat on port 80 should be fine. An even better solution would be to recompile your kernel so that you don't need uid 0 to bind to port 80. I still can't figure out why they have that dumb restriction that you must have uid 0 to bind ports 1024. That's just stupid and it causes far more security problems than it solves today. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: security issue: tomcat on port 80
I run Tomcat on port 80 on my Win32 servers (NT and 2K). I have watched the Windows viruses attack Tomcat with no impact. The one server running IIS (required for our time keeping software) got nailed by a virus within a week of being setup. That server has since had IIS pointed to a different port and placed behind the firewall. I feel much more secure running Tomcat then IIS on Win32. Jim -Original Message- From: Dr. Evil [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 1:48 PM To: [EMAIL PROTECTED] Subject: Re: security issue: tomcat on port 80 How safe is it to have tomcat listening on port 80 running on a RH6.2, which is on the internet ? Did anybody face any security problems ever ? From the conventional point of view, having things run on port 80 has been dangerous because a proc has to have uid 0 to bind to the port. Apache is regarded as safe because the code drops root ASAP and si thoroughly tested and audited. Tomcat is not regarded as safe because it can't drop uid 0. However, the reason why uid 0 is so dangerous for Apache is because it's written in C. Buffer overlflows are almost inevitable in a language like C, with its direct memory access and unsafe pointers. Java bytecode doesn't have any of those problems. It can't manipulate memory or pointers ever. It is much much safer than C will ever be. So I think running Tomcat on port 80 should be fine. An even better solution would be to recompile your kernel so that you don't need uid 0 to bind to port 80. I still can't figure out why they have that dumb restriction that you must have uid 0 to bind ports 1024. That's just stupid and it causes far more security problems than it solves today. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
