Google Site Search

Google
 

Wednesday, April 28, 2010

Security Issue: JBoss and CVE-2010-0738

This is a community courtesy notification for a severe security issue affecting some of the JBoss projects and products. Please refer to the following Red Hat KBase article for more information:

JBoss Products & CVE-2010-0738


As a Red Hat/JBoss enterprise customer (paying), you are already notified via the official channels: RHN, CSP etc. Patches/updated products are available to you.

If you are an user of the community project: JBoss Application Server, then you may be affected. Please refer to the kbase article for possible solutions.


Reference:

JBoss.org Wiki Page for Community Notification

Saturday, April 17, 2010

Social Media increases our connection to the Internet

Most of us use Social Media in one form or the other. Be it Twitter, Facebook, LinkedIn, Four Square, blogger etc. It is a means by which we stay connected to this planet. Your old friend lives thousands of miles away on the other side of the planet, well, you can reach out to him on a daily basis via the social media. You have not met this classmate since kindergarten and now you get connected to him by Facebook or Myspace.

Each time you use social media, you are giving out your privacy, a bit at a time. I am sure one day avid users of the Social media can attest to Scott McNealy's famous saying on privacy. Before getting there, let us look at one phenomenon of human relationships that is getting to be the toughest for individuals - young and older. The social phenomenon of breakups. Breakups are normal psychological phases that individuals go through, in this world.

Scott Bolohan of Chicago's Red Eye has this interesting article on how the Internet is making it harder for him to breakup. I know. I know. The article is funny (at least all that Scott does to trace his old flame). But a deeper introspection of what Scott is trying to communicate will make you understand the grand scheme of things associated with social media.

Since it is a small world and we are connected to one another via mutual friends, it is going to be increasingly difficult not only to breakup but also to find suitable dates. Gena Grish talks about it in the Huffington Post. She has trouble with potential dates googling about her.

What are the alternatives? Stop using the social media? Do not divulge any information on the web? The jury is out. We certainly are entering or entered a Brave New World. Either we embrace it or live in our own shell.

Friday, April 16, 2010

Security :: Community JBoss AS versus JBoss EAP

JBoss Application Server has been a popular (let us call it premiere) open source Java EE compliant application server for a long long time. Naturally, there are tons of users.

Over the years, the developers (the guys writing JBAS) of the community JBoss AS have debated about enabling security in JBAS. We have had heated debates on whether we ship the community version of JBoss AS in secure mode (everything - jmx console, twiddle, invokers secure secure secure secure secure) or in a development mode.

We have over the years had the understanding that JBoss AS will be primarily used by Java EE developers on their desktop to develop business applications. When they are ready to deploy those applications in production, they will have the practical sense to follow guidelines on securing jboss (which has been available in multiple forms in our wiki).

There are no reasonable defaults in security to secure the shipped community version of JBoss AS.

Now, let us talk about the product JBoss Enterprise Application Platform (EAP) that is shipped by Red Hat. Everything in the platform is secured by default. This is the version that customers (including Governments, Financial institutions, Universities, Companies of varying size) use to develop and deploy business applications. The system administrators have to configure the security of EAP to get it working. You cannot just unzip and run your applications.


Why am I writing this blog post?

The reason I am writing this blog post is because increasingly we are seeing multiple security companies that want a leg hold in the industry, using the community version of JBoss AS, to spread FUD. An example is the presentation by Christian Papathanasiou of Trust Wave called Abusing JBoss. Honestly, I find the title offensive. JBoss is a brand. You cannot abuse it.

Let us talk about ethics now. If you are security researcher or vendor, it is ethical to first contact the company or project whose exploits you are going to make public. Before this presentation, neither Christian nor Trust Wave has contacted the JBoss Security Response Team (http://jboss.org/security) or the Red Hat Security Response Team (http://www.redhat.com/security/).

At JBoss, what do we do?
Every time, we find someone with an unsecured JMX Console on the web, our response team folks try to contact the owner of that site to educate them about securing the console. But this is a daunting task. Every developer who wants to have his own website, just uses the community version of JBAS without applying the proper security fixes.

Additionally, the fans of JBoss also try to contact the website owners. We do have a fan following over the years. At JBoss World, they tell us about the same.

I seriously doubt any high profile company has a JMX console that is open to the world. There may be a few but we are actively locating and telling them about security. If you find one, inform them about securing community version of JBoss AS.

Additionally US-CERT has an advisory on this here.


Which JBoss AS should I choose: Community JBoss AS or JBoss EAP?

* JBoss EAP is a product that is officially supported by Red Hat. You get patches, updates, security fixes etc. It is shipped secure.
* If you are using the community version of JBAS, then please please follow the security steps for your instance. If not, you are just giving fodder to the millions of new security companies popping on the block.


If I find a vulnerability in any of JBoss projects and products, where do I report?

Please pass that information to the Red Hat Security response team in any way you choose. The methods are listed at http://www.redhat.com/security. Quick, confidential treatment of your queries and reports will be provided.

Wednesday, April 14, 2010

When will we see the end of the Password era?

I know. I know. Passwords are the simplest means of providing security to applications. It is the simplest piece of knowledge that a subject/user can carry, rather than smart cards, certificates, finger prints, retina scans or whatever stronger forms of security, the world desires.

With the increasing processing speeds/powers of cheap/low cost computers, it will get increasingly easier to crack passwords.

So what is the solution?
* Look to make passwords the strongest? How will I remember all the passwords? I can just write it in my notebook.
* Ensure that the user changes the passwords often and do not allow him to have the last 10-20 recently used passwords? Ok, back to the notebook to keep track of all the accounts and their passwords.

Given the complexity of passwords and the proliferation of accounts that an individual manages in this socially connected, increasingly online world, I would say that the user will probably (wait, will definitely) use the same password in multiple accounts.

So what happens when the apache infrastructure gets compromised and the attacker steals all the passwords? I will have to refer to my notebook to see what my apache password was and which other accounts have the same password. I will then do due diligence in making changes to the password and then feed that information back to the notebook. Lets save paper. We will just maintain the password information in a simple file in my laptop.

I am sorry. I do not have any such notebooks. But my brains are operating at thresholds, right now, in trying to remember all the accounts and their common passwords.

What are the solutions?