December 2000 - openSUSE Security - openSUSE Mailing Lists

Re: [VULN-DEV] The NSA's Security-Enhanced Linux
by miah 26 Dec '00

26 Dec '00

These linux improvments and pitbull are two totally different things though. Pitbull aims to implement full B1 compatibilty into Solaris, while the work the nsa has done just aims to implement a security policy(which you can read at their site) that improves overall security on linux. -miah -- less talk more clue. On Fri, Dec 22, 2000 at 05:18:42AM -0700, Scott D. Yelich wrote: > On Fri, 22 Dec 2000, Ralf-Philipp Weinmann wrote: > > citing http://www.nsa.gov/selinux/background.html: > > [...] > > The result is available for download at the above URL > > as well. Has anyone here toyed with it already ? > > Cheers, > > -Ralf > > Seems like this is a "demo" ... would anyone be able to compare this > system to a system that is not attempting to be a demo -- such as > Pitbull (solaris?)? It frightens me to think that anyone would > trust linux :-> but, alas, who knows. Maybe is enough sugar is > poured on top, it just won't continue to smell so bad. > > Scott

4 6

Re: [suse-security] d0h (Urlaub (Out-of-Office-Reply))
by miah 26 Dec '00

26 Dec '00

Maybe in that suse-security FAQ there should be a section on "sending the mailing list a vacation message" so stuff like this doesnt happen. -miah On Fri, Dec 22, 2000 at 07:12:18PM +0100, Stefan Klueppel wrote: > Leider kann ich Ihre Mail nicht sofort beantworten, > da ich von 25.12.2000 bis 03.01.2001 in Urlaub bin. > > Bei zeitkritischen Angelegenheiten wenden Sie sich > bitte an > Thomas Wieczorek (tw(a)minters.de) > > Gruss, > Stefan Klueppel > > >>> jjohnson 22.12.00 19.10 >>> > > d0h.. i hate when i send replies to the wrong mailing list :P > > -miah > > --------------------------------------------------------------------- > To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com > For additional commands, e-mail: suse-security-help(a)suse.com >

2 1

Re: Re: Re[3]: [suse-security] NSCD
by r.maurizzi＠gvs.it 26 Dec '00

26 Dec '00

> and with the guys that put together a distri and start every possible > service/daemon as default. (this regarding security ;-) Well, to be honest SuSE usually does not have this kind of problem. Other distro (guess which one :) had/have huge problems with installing and starting every possible daemon, or binding highly experimental corba servers to all interfaces on the machine. If nscd it's a problem then we can say so here, and if they want in the next version this will be either removed or fixed. Ciao, Roberto.

2 1

suse firwall and AOL IM
by jonathan 25 Dec '00

25 Dec '00

Happy Holidays all, I am using the SuSEfirewals script from 7.0 on my firewall but now I can't seem to get AOL IM to work. There are no error messages in /var/log/messages. I can connect to the AOL server (toc.oscar.aol.com on port 21) but I don't see any "buddies" connected and they don't show me being on-line. Any help/comments would be greatly appreciated. TIA

1 0

web security
by Kurt Seifried 24 Dec '00

24 Dec '00

I foget which suse guy wrote the web security thingy, and the url, here's another excellent piece of work on the subject: http://pubweb.nfr.net/~mjr/websec/ Kurt Seifried, seifried(a)securityportal.com SecurityPortal - your focal point for security on the 'net

2 1

Re: [suse-security] Attacks Against SSH 1 And SSL
by Kurt Seifried 24 Dec '00

24 Dec '00

> Hi Kurt, > > Not wanting to start a flame war, but here is some extra information to > consider: > > 1. Trusted roots in browsers: > - Yes the list of "trusted roots" that ship with IE and Netscape is an > issue and one that is being looked at by both vendors. Interestingly > this is not because of security concerns but due to performance issues > and size of trusted root stores. > - It is possible to use Active X controls in IE to both automatically > import trusted roots and disable imports. > - Previously to get your Trusted Root in a browser, you just needed to > pay M$ or Netscape a large sum of money. These would seem to be points in my favour =). > 2. CRL's > - IE 5.5 SP1 uses CRL's, as do most commercially developed PKI enabled > applications Check whether "check for revoked certificated" is on or not. It probably isn't. > 3. CA's > - The process of becoming a CA is actually not as trivial as people > think. Here in Australia for example the process of becoming a CA > involves complex Government accreditation and costs around $35k US. This > is without any hardware or software costs. Uhmm, 35k is peanuts, hardware/software are a coupla of hundred k and up, again it's not expensive. Plus you can always go offshore (some of the certs in IE 5.5 are in .... interesting countries). > 4. PGP > - Pretty Good Privacy, would you trust something that claims to be > "Pretty Good" ? Exactly, especially with that teeny little key bug in every version till 6.5.3. > 5. SSL certs. > - Ever signed up for one of these from a CA such as Thawte or Verisign? > The process involves some complex paperwork to establish trust and to > prove your organisations identity and is coupled with some severe > instructions on securing your private key. In most experience this is a > process that is too hard for inexperienced admins. WRONG. I used to have a Thawte cert for www.seifried.org (I figured it was the best way to learn about secure webserving). It took me 20 minutes to get the paperwork done and cost a hundred odd bucks. They also used to sell class 2 personal ID's (verification done by equifax, a major credit bureau, in other words stupidly insecure), all you needed was name/address/etc and social security number, all trivial to get. > 6. Kerberos > - RSA SecurID provides a better solution that Kerberos, as it does not > present issues of pack expiry times. In theory it could be possible to > capture a users pack and then be automatically authenticated to systems. > For single sign on in a secure environment, PKI protected with SecurID > provides for far stronger security than Kerberos. single sign on also means single point to break in =). RSA's ACE server has numerous problems, I'm not terribly enamoured by the company. Kerberos doesn't require certs/etc, a huge advantage for implementation. I could roll my stuff over to kerberos tommorow and users wouldn't really be bothered to much. > 7. Self Signed Certificates > - Who signs a root cert depends on the trust model and organisation > wants to implement. Is the business environment an open or closed model? > It is not always necessary to have a certificate signed by a third > party. Indeed, in a closed B2B environment a self signed root cert can > provide an equal amount of trust as one signed by Verisign. If I am only This root cert needs to be installed in whatever software you use.... this is usually done after the factm getting more root certs in (from an attackers point of view) is way to easy (my follow up covered a variety of methods). > transacting with my own organisation or with partners, there is no need > to involve a third party as I can validate all trading parties. In Most of these companies can't protect credit card data properly (why do they store it in the first place??) and you expect them to setup and run a CA properly? You have a lot more faith then I do ;). > addition once I have created a signing certificate (a jurisdiction) I no > longer have a requirement for my bootstrap certificate, or root cert. Yeah but you have to expire that cert once in a while. > This can be safely exported from the CA and stored safely. By embedding > CRLs into my application, I can revoke a jurisdiction if my signing > certificate is compromised. When I control the CA, this response can be > initiated significantly faster than when a third party is involved. The > third party could be compromised and I do not even know about it. Embedding certs in software raises some points, for one thing an attacker can still modify them. > 8. Open source, versus commercially developed. > - What your focus has been on so far is pretty much open source > security. I am a huge fan of open source development however in this There aren't really any widespread closed source crypto things =) All the important algo's/methods are publically documented to death and have been beaten on repeatedly. I picked on some commercial products in my two articles =). I don't really see the flaws in ssh/ssl as having anything to do with opensource verse close sources. > instance commercially developed software provides much greater security. > In an enterprise environment, or where I was committing high value > transactions, I would not even consider using SSH or out of the box SSL. Hopefully others will come to learn this =). My articles on ssh/ssl is an effort to educate people, make them realize these solutions are far from perfect as many seem to think. > The use of Reduced Sign on PKI toolkits with Certificates provides a > much better method of providing security. Unfortunatly, these types of > products are to expensive for low value transactions (and the use > questionable due to the value of the information being protected). Yup. Any who cares anyways, credit card companies just pass the cost on to consumers and merchants (who pass the cost on to consumers). Consumers need to stand up and make some noise, egghead just had 1.3 million card numbers stolen, great. > 9. Sliding security scale > - Security can be described on a scale ranging from DC to AR. At one end > of the scale you have Admins who don't care, the other extreme is Anal > Retentive. Both extremes are inherently bad for the protection of > systems. The DC admin doesn't believe that his or her system is worth > protecting. While the AR admin believes no security measures offer > enough protection and hence refuses to do anything. Well I would hope everyone realizes no security is 100%, it's about striking a balance, aka "risk management". It's fine (IMHO) for a major company with say 500 million a year in revenue to suffer say 3 incidents that cost them a couple tens or hundreds of thousands of dollars. This is why we have insurance. > There are however products that sit on various places on the scale with > the cost increasing exponentially as you progress from DC to AR. > Products such as PGP, SSH, and SSL out of the box sit just to the right > of DC. Cryptographic Toolkits such as SSL-C, Crypto-C, Cert-C and WTLS-C > from vendors such as RSA Security and Baltimore take you further along > the scale (as they enable you to rewrite applications to improve their > security). PKI products progress further to the right and when combined And way to many companies make a mess of things when they roll thier own. Look at eschwab's password storage mechanism. Whooops. > with Two Factor or Three Factor authentication (SecurID, biometrics, > smart cards) you are as close to AR as you can get. Fortunately these products are coming out (I saw a nifty smart card reader with thumbprint scanner, you could setup the smartcard to need a PIN and thumbprint to access it, very good stuff). > The question is, which part of the scale should a good admin reside? The > answer depends on the value of the information they are trying to > protect. Personally, I use a self signed Cert, created using ssleay, > combined with user name and password to access my email remotely. > However the NCA use cryptographic toolkits, with custom applications and > three factor authentication. Why? Their email is a little more valuable > than mine. > > In summary, the type of attacks described by yourself, while possible, > present no real threat to an organisation because the complexity of the > attacks do not really justify the benefit gained from the retrieval of > information. If I was to fall victim to a man in the middle SSL attack > while shopping online, AMEX pick up the bill, not me personally. Uhmm. No. Have you downloaded dsniff and used it? It's trivial to do these attacks. Especially SSL ones because you just do a man in the middle while they are on the insecure part of the site (ie poisoin their dns). See the article below all this (the article is over a year old, wheeep). > The true enemy to security is not pie in the sky exploits as you have > described but apathy in the boardroom and by IT managers to implementing > a security policy and products in the first place. Articles such as > yours, while valuable from an academic view point do not assist this cause. Pie in the sky. yeah. ./configure ; make ; then use it. > Regards, > > Kelvin Rundle. > > Further Reading: > http://computerworld.idg.com.au/cwt1997.nsf/all/6BBEB57277625B344A2569A6007… ======================== September 30, 1999 - The title is a bit scary, but I wanted to get your attention (worked, didn't it?). Most security experts have been aware of problems with SSL, but generally speaking we haven't said much because there wasn't much of a replacement available for it, and it hasn't been exploited extensively (chances are it will be, though). I'll start with an explanation of the basic attack, followed by some methods to protect yourself, and finish with an interview with Dale Peterson of DigitalBond and the summary. How to do it Let's say I want to scam people's credit card numbers, and don't want to break into a server. What if I could get people to come to me, and voluntarily give me their credit card numbers? Well, this is entirely too easy. I would start by setting up a web server, and copying a popular site to it, say www.some-online-store.com, time required to do this with a tool such as wget is around 20-30 minutes. I would then modify the forms used to submit information and make sure they pointed to my server, so I now have a copy of www.some-online-store.com that looks and feels like the "real" thing. Now, how do I get people to come to it? Well I simply poison their DNS caches with my information, so instead of www.some-online-store.com pointing to 1.2.3.4, I would point it to my server at 5.6.7.8. Now when people go to www.some-online-store.com they end up at my site, which looks just like the real one. How to prevent being taken Most forms online are not on secure servers, but the data you provide is usually sent to a secure server, which leads to one of the major problems. The form data may not be going where it should. A simple attack is to have the fake site, and a form that takes the data, without using a secure server at all. How many of you actively check the source HTML of pages you are plugging your credit card data into? The title bar should start with https:// followed by the sitename (i.e.: https://www.microsoft.com/). You should also examine the HTML source to make sure the form data points to where it should go, you should see something like: <form method="POST" action="/order.cgi"> or: <form method="POST" action="https://www.some-online-store.com/cgi-bin/order.cgi"> If a store is using the "GET" method, do not buy from them, any data you enter will be passed along as the query string, if you look in the text of your address bar you will see your credit card info. If a store specifies a relative link (i.e.: /something/something.cgi) then make sure the current site you are at is a secure server, and that the certificate is legitimate. If the link is absolute, and points to an IP address, be suspicious, I personally would not buy if this were the case. Ideally the link should point to something like "https://www.some-online-store.com/cgi-bin/order.cgi", and you should first browse to that site, and make sure the certificate is legitimate, before hitting the submit button on your order form. Most current SSL attacks are based on fooling the user, more so than breaking the technology. If you are vigilant, and check certificates before you submit to sites you will be a little safer (but not completely). SSL Certificates contain various pieces of information, such as who issued them, when it was issued, when it expires, who it was issued to and so forth. Who it was issued to (usually the "subject") is a very important field, and the issuer field. To view the certificate details double click on the lock icon, usually at the bottom left of the screen in Netscape, and at the bottom right in Microsoft Internet Explorer. Let's take https://www.microsoft.com/ for example, the Issuer field looks like: OU = Secure Server Certification Authority O = RSA Data Security, Inc. C = US The C stands for country, the O for organization (usually the company's name), and the OU stands for organizational unit (a division of the company). The subject field looks like: CN = www.microsoft.com OU = mscom O = Microsoft L = Redmond S = Washington C = US The S stands for state, the L for locality (the city), and the CN is the certificate name (the site it applies to). Make sure all these are spelt correctly, many attackers will use domain names that look familiar (such as miicrosoft.com) in order to get legitimate certificates. Taking these precautions every time you use an SSL secured service is tedious, and underlines one of the major flaws with SSL, in that is susceptible to "social engineering" attacks. Another flaw in SSL is that it only secures the session, it doesn't secure any actually transaction. This means if someone does steal your credit card number and use it online, it is almost impossible to prove that it wasn't actually you that issued the order. SSL does allow for the client to authenticate to the server, however very few people have digital certificates compatible with this (I have one, and know of perhaps a half dozen other people, a definite minority). In addition to this the major certificate vendors have stopped issuing the personal certificates that guarantee the person's identity, so they are a dead end. There are newer protocols and systems that allow for two parties to safely conduct transactions with all these features. The following is an interview with Dale Peterson of DigitalBond (www.digitalbond.com). DigitalBond is currently working on a product to secure Internet transactions, and is targeted at brokerage houses which have many thousands of users on a daily basis, making them an especially tempting target. -------------------------------------------------------------------------------- Kurt: Is SSL dead? Dale: No. It is a fine session encryption protocol. The editor for the TLS (new name for latest version of SSL) spec works at Certicom and is our partner. I've talked this over with him, and he is very insistent that SSL is not broken. But he does say it suffers from all the problems we have discussed in these emails and could be augmented with a transaction protocol. I think that it certainly shouldn't be the protocol for most e-commerce transactions, but for the exchange of private data over the Internet it is ok. Kurt: What do you envision replacing SSL? Dale: We see a lot of businesses that are doing two-party transactions. Nice and simple, unlike the multi-party bank card model that SET addresses. We have developed a two-party transaction security model that we thinks meets the needs of Internet Brokerages, Internet prescription drugs, and other two-party transactions. It is being reviewed by Carnegie Mellon University, and they will publish a paper this year. Kurt: Should we be educating users about these technologies? Do they care? Dale: The most important education needed is that SSL transactions are not secure. The whole Internet community has been fed this baloney because SSL was around and easy. I have found it difficult getting reporters to even believe this vulnerability exists, even with a live demo. The response is "That can't be true. We would all know about this if that were true". That is why I think this story will be big when it breaks in the mainstream press. -------------------------------------------------------------------------------- Summary: SSL is NOT dead. It is just an inappropriate security system for many Internet based transaction systems. As with many things on the Internet the growth of online sales, and especially the growth of online brokerages has been stupendous. SSL was simply not designed with systems like these in mind, and systems like DigitalBond are attempting to fix this. Chances are in 5 to 10 years that the existing systems will be found to be "weak", and replaced with better systems.

2 1

interpreting tcpdump output -- do I have a problem?
by Robert C. Paulsen Jr. 23 Dec '00

23 Dec '00

Hello, I ran tcpdump and got some unexpected (to me, at least) output. Here is a short example: ============================================================================================================================= 20:03:42.105589 home.paulsen.org.clvm-cfg > ns3.texas.net.domain: 51903+ PTR? 2.78.40.216.in-addr.arpa. (42) 20:03:42.313064 ns3.texas.net.domain > home.paulsen.org.clvm-cfg: 51903* 1/3/3 PTR holder2.net78.connectsouth.net. (209) (DF) 20:03:42.313975 home.paulsen.org.clvm-cfg > ns3.texas.net.domain: 51904+ PTR? 3.0.207.207.in-addr.arpa. (42) 20:03:42.368919 ns3.texas.net.domain > home.paulsen.org.clvm-cfg: 51904* 1/2/2 PTR ns3.texas.net. (158) (DF) 20:03:43.209947 home.paulsen.org.clvm-cfg > ns3.texas.net.domain: 51905+ PTR? 91.183.140.216.in-addr.arpa. (45) 20:03:43.243013 ns3.texas.net.domain > home.paulsen.org.clvm-cfg: 51905 1/2/2 PTR mail.aurasoma.net. (177) (DF) 20:03:45.668535 home.paulsen.org.clvm-cfg > ns3.texas.net.domain: 51906+ PTR? 161.67.231.209.in-addr.arpa. (45) 20:03:45.879046 ns3.texas.net.domain > home.paulsen.org.clvm-cfg: 51906* 1/2/2 PTR paulsen.net.criticalpath.net. (181) (DF) ============================================================================================================================= (home.paulsen.org is my local host -- it has a class-c IP address of 192.168.0.1 and is connected to the Internet via a Win2K box that uses a cable modem. texas.net provides the name server.) clvm-cfg is port number 1476. There were many other lines in the tcpdump output with "nearby" port numbers. Does this mean that those services are really in use? Or are these ports just being dynamically assigned for other uses. It seems unlikely that my system would really be using the services those port numbers are assigned to -- most of them seem to have something to do with license management of applications I never heard of before. -- ____________________________________________________________________ Robert Paulsen paulsen(a)texas.net

2 2

Attacks Against SSH 1 And SSL
by Nix 23 Dec '00

23 Dec '00

Here's something that may be of interest to all you security buffs out there.... (and for an added bonus prize, it's written by Kurt, one of the spamme^H^H^H^H contributors to the list *grin*) http://slashdot.org/articles/00/12/18/0759236.shtml http://www.securityportal.com/cover/coverstory20001218.html "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing. Nice one Kurt... Cheers -Nix -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

2 1

SuSEfirewall
by Ralf Corterier 23 Dec '00

23 Dec '00

Hello, I have set up a dialup router/mail server for private use (suse 6.4). To make it more secure I use SuSEfirewall. There is webmin running on the machine (I am aware of the security risks this may impose!!). First I had it running on port 10000, but then I set it up to use ssl and changed it to a different port (above 1024). I set FW_PROTECT_FROM_INTERNAL="yes" and allowed access to webmin in the line FW_SERVICES_INTERNAL_TCP="ssh squid squid-alt pop3 smtp webmin". There are corresponding entries in /etc/services. FW_ALLOW_INCOMING_HIGHPORTS_TCP="no" is set also. From the outside nothing of this is visible (checked with nmap). When changing the webmin port I did not change the corresponding entry in /etc/services. As far as I understand the comments in firewall.rc.config, this should not allow access to webmin anymore, because the only high tcp ports accessible are 10000 (old entry in /etc/services for webmin), squid and squid-alt. Webmin is running on a different port. This port has no entry in /etc/services. But Webmin is still accessible. Shouldn't this be prevented by setting FW_ALLOW_INCOMING_HIGHPORTS_TCP="no" ? Even more, when I delete webmin in FW_SERVICES_INTERNAL_TCP and run SuSEfirewall again, it is still accessible. Does this mean FW_ALLOW_INCOMING_HIGHPORTS_TCP="no" only protects to the outside? Thanks for any advice. Ralf Corterier

1 0

d0h
by miah 22 Dec '00

22 Dec '00

d0h.. i hate when i send replies to the wrong mailing list :P -miah

1 0