Timing is a wonderful thing, I'd just published a very similar issue with IE about an hour before the Firefox issue hit full disclosure: http://www.nth-dimension.org.uk/news/entry.php?e=1 56579087. If you run IE don't feel left out, we can run arbitrary Javascript via your style sheets too.
Speaking as one of the folks behind the OpenVAS (www.openvas.org) fork, there are plenty of people interested in maintaining an open source alternative. Interestingly many of these people have attempted to work with Tenable in the past and have had their contributions ignored. IMO Tenable didn't understand how they could make money off the Nessus project without closing the source.
As a side point, it would be interesting to understand how Tenable have dealt with contributions that they did accept for version 2 - have they been removed completely from version3?
Consider the following examples, all culled from roles I've worked in. Open source vendor A doesn't bother to respond to a remote hole in a webmail application, whilst open source vendor B patches a remote hole in their VoIP application immediately. Closed source vendor A forwards our advisory regarding a remote hole in a monitoring tool directly to the main security mailing lists, whilst closed source vendor B sits on a remote hole in a banking application for months. So how does responsible disclosure fit in, in these circumstances? Ultimately it doesn't, security companies must be willing to publish and be damned in order that the vendor Bs of the world are forced to adapt. At work we give 30 days for confirmation and fix plan from vendors, privately I work on a 14 day cycle.
It showed my IP blocks as having raised concern, despite the fact that they're not on any black lists and I can't why it has drawn that conclusion. Also, using the domain checker, it has no knowledge of non-TLDs meaning it will treat xxx.org.uk and yyy.org.uk as the same domain - org.uk.
Nono, whilst I complement you for not falling into the US-is-teh-interweb, kids.us is where you should locate such right-think. Come to think of it, gov.us, edu.us and mil.us might just work too;).
No, the point of the Blackhat presentation was to tell the world that the watchdog could be fooled and that an enabled shell was possible. The specifics of the exploit presented were not the news story. Lynn's work defeats one of Cisco's much vaunted security mechanisms. Any Cisco exploit would have done.
The points I was trying to make were a) that merely using higher level languages to abstract yourself away from how the machine executes, won't make a blind bit of difference, because the bad guys can do the same and have done, to use SQL injection as an example and b) just because you validate in your program at the initial user input, someone might use your lower level functions without doing so, so every function must (complexity aside) check its input.
Erm, I'll give you +4 elloqence as you've just given a much clearer description of what I meant.
When I referred to all components, I didn't just mean those components to which the user of the application was exposed, but every piece of code that took input in i.e. every function. The encoding I referred to should take place between these components, precisely to avoid scenarios such as unusual surnames.
It's all very good advocating the use of languages that mitigate against heap and stack overflows et al. But as the recent XML RPC vulnerability in PHP applications should reinforce, the bad guys are migrating to higher level language attacks too.
The fundamental problem is that all too often, different components of a system have are implemented with different input validation. For example a web browser component running an web application may accept all text input, whereas the backend database is only expecting a subset of text inputs.
Developers should establish what input the lowest level component and highest level components will require to get the job done and validate input into all components subject to these requirements. Where the lowest and highest level components have different requirements then the developer needs to define some method of encoding values that would otherwise be considered invalid, and ensure that all components enforce this encoding.
Without being explicit, don't count your chickens if you're using Perl based CMSs. I'm aware of issues with at least one of the main Perl based CMSs which could ultimately lead to a full server compromise and am currently in talks with their developers about how to fix it. The last thing any sys admin, web developer or web site owner should do, is attempt to sit on their laurels. Yes, code will have bugs. Go forth and audit.
Physically, yes... I was thinking more from the perspective of the Ahimsa & Italian situations where the server was seized without Indymedia being aware of what was occurring. That won't happen with my server, since they'd need to comply with UK law and contact me (as opposed to Rackspace etc).
Nah, I just suffer from a split personality disorder. Actually it may well be true that *someone* is investigating putting a server in Sealand, however the same was suggested last time and nothing came of it. Fortunately I own the company that owns the racks my servers are located in, so anyone trying to take 'em down will have to come through me to get to them.
When the UK servers were seized, I was the first techie to put up a mirror. FYI, I was shipping around 200k/s for over 40 odd days. The UK mirror alone is around 9Gb in size, not to mention the other sites that the original UK server was hosting. The fact is that we now have 8 servers handling www.indymedia.org.uk, spread globally around the world. Hosting a mirror takes serious amounts of good will.
One thing governments appear to miss is the fact that we DON'T log IP addresses.
Another thing to consider is that some parts of the IT industry actively require cross skilled individuals. To give you some idea, I started off as a UNIX system administrator but now work as a penetration tester. Working in the current role, while everyone has their fu - for some it's web apps, for me it's Solaris and for others, well you get the point. The fact is that in the last month, I've done assessments requiring a good level of knowledge of Cisco, ASP.NET, Windows 98, Solaris 10, Perl, Windows 2000 and RedHat Linux... if I turned round to our tech director and said no, I wouldn't do one of other of these not only would I be out the door but I'd be bloody foolish, since they've all be interesting assessments.
I'm quite happily running NetBSD's pkgsrc on Solaris. pkgsrc supports a number of commercial Unix flavours although I believe Solaris was the first to be added. Hell, you can even use it on a Linux distribution. FWIU the Gentoo effort will be along similar lines although this is yet to be seen.
IIRC. Sun are working with Fujitsu on the next generation of high end SPARC systems, however they're also working with AMD on low/mid tier systems and will more than likely be supporting IA64 too. Sun will support whatever you as a customer want, and thankfully some of us want SPARC kit.
Slashdot Mirror
Timing is a wonderful thing, I'd just published a very similar issue with IE about an hour before the Firefox issue hit full disclosure: http://www.nth-dimension.org.uk/news/entry.php?e=1 56579087. If you run IE don't feel left out, we can run arbitrary Javascript via your style sheets too.
Perhaps Steve would like to present his findings at the next DunceHats security conference. We could do with people of his caliber.
It's called Basel II.
Speaking as one of the folks behind the OpenVAS (www.openvas.org) fork, there are plenty of people interested in maintaining an open source alternative. Interestingly many of these people have attempted to work with Tenable in the past and have had their contributions ignored. IMO Tenable didn't understand how they could make money off the Nessus project without closing the source.
As a side point, it would be interesting to understand how Tenable have dealt with contributions that they did accept for version 2 - have they been removed completely from version3?
You may want to check out www.gnessus.org then - we have the GNU/Debian source and we intend to fork() :)
Like eTrust AC per chance. Having implemented this as part of a previous role, I would thoroughly recommend it.
Consider the following examples, all culled from roles I've worked in. Open source vendor A doesn't bother to respond to a remote hole in a webmail application, whilst open source vendor B patches a remote hole in their VoIP application immediately. Closed source vendor A forwards our advisory regarding a remote hole in a monitoring tool directly to the main security mailing lists, whilst closed source vendor B sits on a remote hole in a banking application for months. So how does responsible disclosure fit in, in these circumstances? Ultimately it doesn't, security companies must be willing to publish and be damned in order that the vendor Bs of the world are forced to adapt. At work we give 30 days for confirmation and fix plan from vendors, privately I work on a 14 day cycle.
It showed my IP blocks as having raised concern, despite the fact that they're not on any black lists and I can't why it has drawn that conclusion. Also, using the domain checker, it has no knowledge of non-TLDs meaning it will treat xxx.org.uk and yyy.org.uk as the same domain - org.uk.
Do you work for ICANN? :)
Nono, whilst I complement you for not falling into the US-is-teh-interweb, kids.us is where you should locate such right-think. Come to think of it, gov.us, edu.us and mil.us might just work too ;).
No, the point of the Blackhat presentation was to tell the world that the watchdog could be fooled and that an enabled shell was possible. The specifics of the exploit presented were not the news story. Lynn's work defeats one of Cisco's much vaunted security mechanisms. Any Cisco exploit would have done.
The points I was trying to make were a) that merely using higher level languages to abstract yourself away from how the machine executes, won't make a blind bit of difference, because the bad guys can do the same and have done, to use SQL injection as an example and b) just because you validate in your program at the initial user input, someone might use your lower level functions without doing so, so every function must (complexity aside) check its input.
Erm, I'll give you +4 elloqence as you've just given a much clearer description of what I meant.
When I referred to all components, I didn't just mean those components to which the user of the application was exposed, but every piece of code that took input in i.e. every function. The encoding I referred to should take place between these components, precisely to avoid scenarios such as unusual surnames.
It's all very good advocating the use of languages that mitigate against heap and stack overflows et al. But as the recent XML RPC vulnerability in PHP applications should reinforce, the bad guys are migrating to higher level language attacks too.
The fundamental problem is that all too often, different components of a system have are implemented with different input validation. For example a web browser component running an web application may accept all text input, whereas the backend database is only expecting a subset of text inputs.
Developers should establish what input the lowest level component and highest level components will require to get the job done and validate input into all components subject to these requirements. Where the lowest and highest level components have different requirements then the developer needs to define some method of encoding values that would otherwise be considered invalid, and ensure that all components enforce this encoding.
That's funny, these guys seem to believe Ireland is part of the EU.
Without being explicit, don't count your chickens if you're using Perl based CMSs. I'm aware of issues with at least one of the main Perl based CMSs which could ultimately lead to a full server compromise and am currently in talks with their developers about how to fix it. The last thing any sys admin, web developer or web site owner should do, is attempt to sit on their laurels. Yes, code will have bugs. Go forth and audit.
Physically, yes... I was thinking more from the perspective of the Ahimsa & Italian situations where the server was seized without Indymedia being aware of what was occurring. That won't happen with my server, since they'd need to comply with UK law and contact me (as opposed to Rackspace etc).
http://www.nth-dimension.org.uk/mrtg/bulgaria.publ ic-internet.org_195.85.245.2.html makes quite the point quite nicely, watch the traffic rise.. and this is just 1 of 8 mirrors.
Nah, I just suffer from a split personality disorder. Actually it may well be true that *someone* is investigating putting a server in Sealand, however the same was suggested last time and nothing came of it. Fortunately I own the company that owns the racks my servers are located in, so anyone trying to take 'em down will have to come through me to get to them.
When the UK servers were seized, I was the first techie to put up a mirror. FYI, I was shipping around 200k/s for over 40 odd days. The UK mirror alone is around 9Gb in size, not to mention the other sites that the original UK server was hosting. The fact is that we now have 8 servers handling www.indymedia.org.uk, spread globally around the world. Hosting a mirror takes serious amounts of good will.
One thing governments appear to miss is the fact that we DON'T log IP addresses.
Indymedia was born in the US. I can assure you that it exists state-side.
Word has it, that they're not. Truth and counter truth, who do you believe? Me, I'm just an admin for the UK servers.
Another thing to consider is that some parts of the IT industry actively require cross skilled individuals. To give you some idea, I started off as a UNIX system administrator but now work as a penetration tester. Working in the current role, while everyone has their fu - for some it's web apps, for me it's Solaris and for others, well you get the point. The fact is that in the last month, I've done assessments requiring a good level of knowledge of Cisco, ASP.NET, Windows 98, Solaris 10, Perl, Windows 2000 and RedHat Linux... if I turned round to our tech director and said no, I wouldn't do one of other of these not only would I be out the door but I'd be bloody foolish, since they've all be interesting assessments.
I'm quite happily running NetBSD's pkgsrc on Solaris. pkgsrc supports a number of commercial Unix flavours although I believe Solaris was the first to be added. Hell, you can even use it on a Linux distribution. FWIU the Gentoo effort will be along similar lines although this is yet to be seen.
IIRC. Sun are working with Fujitsu on the next generation of high end SPARC systems, however they're also working with AMD on low/mid tier systems and will more than likely be supporting IA64 too. Sun will support whatever you as a customer want, and thankfully some of us want SPARC kit.