Hot:

Released to the public on October 22 Canonical’s latest and greatest Ubuntu yet “Karmic Koala 9.10“.  For many folks using a Linux distribution probably ranks up there with a visit to the dentist, but I have to say that as the kernel keeps improving in leaps and bounds the software wrapped around it can just work on the majority of hardware without issue.

Sure many folks may try it out and find out that it ‘does not work’ with their specific hardware, but compared with last years 8.10 the numbers are down with the sad exception of two particular vendors; ATI and Intel.  ATI recently dropped support for much of their older hardware, but then released a new series of drivers that do support.  Thankfully using the older drivers or using the open source communities versions can at least get them working, if you have problems with the more supported drivers.  Intel on the other hand has basically thrust it’s middle finger up at the linux community with a blatant refusal to provide open source to allow many distributions to be able to integrate support, so for many it means booting to a broken system, and downloading proprietary drivers and praying it works.  Obviously this isn’t the end of the world, but from my perspective a seriously ‘good’ reason to avoid using Intel hardware,  especially if you want to use wine to run Windows games or applications, you’d do so much better with non-Intel chipsets.  nVidia has the best support out of the box for most people not only linux users, but also windows users that it’s becoming a staple requirement.  Don’t get me wrong, Intel does provide drivers, but do not expect them to work directly from installation.  In some cases the generic drivers get installed and it works, in other cases you’re faced with non-working hardware and off to the various support forums seeking a solution.  Thankfully they are available.

In my situation I decided to get a new laptop and specifically bought a Compaq CQ60 which features NO Intel or ATI hardware, simply so I could avoid any hassles.  I’m pretty good at fixing these issues, but if I am spending money and the amount is equal, why buy something with hardware that will not work?    So without further adieu, I release my notes on installing Ubuntu 9.10 x64 on this laptop.

Continue reading 'Ubuntu 9.10 “Karmic Koala” Release Candidate – Installation Notes'»

Hot:

To be quite frank no language is secure, no language was built from a security perspective.

 

So….

Many people these days seem to get it in their head that there are secure designs in the world, and I digress, no their isn’t. Nobody thinks deeply about security except those with a great deal to lose, and they pay very heavy for it.

Your bank is not really that secure.  Your data is not really secure.  Your personal government files are not secure.  Your home is not secure.  Your business is not secure, your car is (phht a joke!) not secure.  What does this tell you?

Well what did September 11, 2001 tell you?  What did Hurricane Katrina tell you?  

I think it’s telling us, that no ‘system’ or ‘process’ is secure by design.  Security is something we thought about afterwards, generally speaking when someone else quite distinctly shows you the insecurity.

When it comes to software, we cannot think that ‘security’ is job #1.  We’d be lucky if they even considered it in a fleeting moment, let alone design with it in mind.

So why would we think anything we do on computers or online, is secure?  It isn’t,  it’s even worse.  Online banking/payment systems are not secure, our Media players are not secure, our email and IM is not secure, our web browsing is not secure, nothing in our software is secure… 

…unless we want it secure. 

So if we want to think about secure design, what should we use as a language, and is there any languages we should avoid.  Well a ton of FUD is being generated towards PHP, like it’s the first language to have a high degree of problems.  Probably Microsoft detractors trying to suck people disillusioned by PHP info thinking that Visual Studio will be the holy grail for secure programming.  Only a total idiot could have that type of an epiphany.  Anyways, my thoughts on this subject have been heightened by a recent thread on Bugtraq by a group you’d think knew what they were talking about.  But it shows that its all opinion with little fact.  I question some of this and downright disagree with vast sums of it.

Let me quote:

> —–Original Message—–

> From: Thomas M. Payerle

> Sent: Thursday, February 23, 2006 1:38 PM

> To: Christine Kronberg

> Cc: Gadi Evron; bugtraq@securityfocus.com

> Subject: Re: PHP as a secure language? PHP worms? [was: Re:

> new linux malware]

>

> >> 1. PHP is the “serious” or at least open-source/Linux/security

> >> freak’s choice for web development. Mine as well (although as many

> >> still say, Perl does a better job).

> While PHP is extremely popular, especially in open-source and

> Linux communities,I am not sure it qualifies as the defacto

> choice of “serious” web developers.

 

What language is ranked the ‘defacto choice of “serious” web developers’? 

When I talk to them I typically hear three answers, Javascript, PHP, and ASP. When I look on google to see if there are any trends out there I find most ‘serious’ web developers typically use PHP and a lot of the design houses use ASP.

For developers in general (app, web, etc.)

 

Which programming languages are currently in use at your company for development?

C – 32%

C++ – 54%

C# – 72%

Delphi – 7%

Java – 66%

JavaScript – 50%

PHP – 16%

Perl – 34%

Python – 8%

Ruby – 1%

TCL – 6%

Unix shell scripts – 42%

Visual Basic – 62%

Other interpreted languages – 33%

 

Pasted from <ComputerWorld>

 

According to this I would rank PHP as #3.

Javascript, Perl, then PHP, followed by Python and TCL.

ASP didn’t even qualify (probably a chunk of that ‘other’). 

So what about web developers specifically?  Do they simply use Dreamweaver and frown on the rest?  It’s really up in the air.  A lot of choices out there.  Lets pick a couple examples.

The US  (GAO) General Accounting Office decided that PHP was the choice over java for such reasons as (gasp) security! 

Infoworld

Then there is this guy who thinks the sky is falling.

Nut Case Against PHP

May as well say Windows is a growing target for trojans and worms.  How about Mountains are a growing target for rain?  Taxi drivers are a growing target for passengers?  Runways are a growing target for airplanes (literally!)?  See how foundless this type of comment is?  Javascript has so many holes in it, they cannot realistically be patched, so the best solution is restricting what sites can use javascript, again another solution that has never worked, but at least allows us the whitelist-approach to the solution.

So it’s fairly obvious something with a HUGE penetration into the server market, cost is nil, and developers are abundant around the world,  is to be considered a ‘growing target’ for something!!  If peanut butter became the next language and used by a growing group, guess what?  It too will experience this type of exploitation, it’s part of life.  It’s what we as people do. 

Anyways, lets get back to our bugtraq discussion.

> And I did not think it was as popular in the security

> community (when I occasionally scan one of the reports on the

> frequent PHP based applications that grace this list, I

> thought exploit code is as often as not given in

> Perl:)

Ridiculous and nonsensical comment.  Perl is typically used because it’s easier to write PoC or exploits in.  I personally prefer Python.

Remember, we are here because nobody thinks about the ‘right’ way, just the fast or simple way. What difference does the PoC source mean?

 

> >> 2. Developing secure applications in PHP is difficult, as one of

> >> PHP’s creators said recently – even to him after years of trying.

> The number of PHP applications getting reported on bugtraq

> would seem to support this, although likely also contributed

> to the fact that it is popular, and perhaps that it is (or at

> least has the reputation of being) of being easy to program,

> leading to programs written by people without understanding

> of security implications.

Again, just like any other language or ‘code base’ when we learn from our mistakes we explore new avenues and not necessarily like what we see.  PHP was the least designed to do only a trifle amount of what it has turned into.  It went from being a very simple ‘scripting home pages language’ to a very ‘sophisticated server side language’ in better course of a few years.  In that very short time frame a LOT has been learned about writing secure code in PHP, and the next generation of stuff will be leaps and bounds better, however; a LOT of old code (some no longer supported) needs to be fixed and the fact that the community is working to fix it is king.

But that doesn’t mean that the ‘need’ for secure code is present in all cases.  A Good example of this is ACID, for the longest time the only front end for the popular IDS called Snort used by a security analyst to gather information.  Simply said, one of the worst written apps in PHP probably ever “from a security perspective”. My analysis would be to chuck the whole thing out and rebuild, something a lot of people are currently doing and/or considering, or in the least, aware of the reality.

But in fairness to the author he did not design it ‘for secureness’ he designed it to view insecure data.  He did not think the average ‘user’ would ‘need it’ secure. Again, if the need for something in the software is not perceived, why would you waste time designing it.

The latest push has been into BASE development which has improved, is still nothing secure or even remotely close.  This team still is trying to grasp rewriting the application.  I personally think this was written this way for a reason, but I digress.

These were developed BY SECURITY PROFESSIONALS yet even they failed to account for writing secure code.  What does this tell you, I know what it tells me.  That nobody understands secure code in the first place, so how can they write it? Do people today still think that BASE needs to be written securely?  Back to our discussion:

 

> >> 3. Staying on top of new PHP vulnerabilities has become

> impossible,

> >> popping around everywhere.

> While I concede I am less than happy about the frequency with

> which patched versions of php come out, and most versions

> include some security related patches, I do not think it is

> impossible.  Furthermore, most of the “security”

> patches have been rather localized, and affect only a small

> number of functions and often only in rather specific

> circumstances, and with some knowledge of the PHP

> applications running on your system you can often leap frog

> over some of the versions.

 

 

I’m not quite following this statement, but it would certainly be the one I agree mostly with.  Most patches are good at fixing the issue with the function.  Typically has to do with no longer trusting some data source, and viola it more secure. But it’s similar to patching C functions also.  Or Perl, or Javascript, so why is PHP being singled out?

If you understand the C code, you can fix the problems when they are pointed out to you.  It seems silly to say, but it’s true.  But what is the likeliness of the developer being able to see the problems in his own code.  I think it’s stupid to comment on, but people are inherently egotistical, and programmers even more so.  When it comes to being honest with themselves and seeing their flaws for what they are we seem to emit a hormone that allows our senses to ignore our own, and home in on other peoples.  So, it’s quite unlikely the average developer is going to notice his or her own security flaws.  They will require someone  less in tune with their code, or picks up their hormone.

 

> Most bugtraq messages with PHP in the subject appear to be

> holes in specific applications, usually due to programming

> errors on the part of the application author.  This does not

> mean the language is inherently insecure; although it may

> indicate that it is difficult to write secure PHP code.  It

> could also mean that PHP is easy enough to program that a lot

> of people without knowledge of how to program securely are

> writing PHP code.

Again, I don’t understand what you would define a secure vs. insecure authoring language.  It’s difficult to write secure C code.  It’s difficult to write ANY code, if your not familiar with it, let alone expert with.  So…back to reality…

No language is secure to start with, so your choice is either defined by:

• Application
• Usage
• Availability
• Cost

 

Even if ‘Secure’ was in there, how would you measure it?

Some people never grasp this. 

Then what comes along…I see this fellow has figured this out:

 

On 22/02/06, Kevin Waterson wrote:

> This one time, at band camp, Gadi Evron wrote:

>

> > 3. Staying on top of new PHP vulnerabilities has become impossible,

> > popping around everywhere.

>

> What vulnerabilities in PHP?

> Are implying the fault is within the language itself?

 

I think Gadi meant vulnerabilities in PHP applications; though the language doesn’t make it particularly easy to write secure code.

 

> This is akin to saying C has vulnerabilites because some script kiddie

> wrote a poor application.

 

Like this ?

 

“We can give you advice on how to write good cryptographic code. Avoid any programming language that allows buffer overflows. Specifically:

don’t use C or C++” — Practical Cryptography, Schneier and Ferguson,

(p149 in my copy).

 

It’s a point of view that has
something to be said for it. You *can* write secure code in C and PHP, but it takes a lot of care and most programmers don’t take that care. I’ve been told privately that one penetration tester could gain system privileges on the majority of webservers he checked; that used to surprise me, but doesn’t any longer. I don’t whether that’s a ‘vulnerability’, ‘disadvantage’ or ‘feature’ of PHP and other scripting languages.

cheers,

Jamie

–

Jamie Riden

 

Agreed.  That doesn’t surprise me anymore either .  Why aren’t we surprised by this?  Simple.  We understand that servers are built with money, and nobody wants to spend more money than they have to.  LAMP (Linux, Apache, MySQL, PHP) is a very common web server setup and can be rolled out quickly, easily, and cheaply.  They need little maintenance, and if they aren’t harmed by the users or the guests, then they can stay running for a long time.   If they get infected or hacked, or whatever, they dump the site, and recreate it somewhere else.  If they need to, they can revert back to a old backup of the site once patching a particular hole. 

Why worry about secure software“it doesn’t exist”.

I think this is the mentality that needs to be changed now.

When people think security in their applications they realize that 100% success isn’t going to happen, and that maybe all they can truly offer is 10% or maybe 20% towards that goal.  So they give up or don’t bother.  I hazard that adding that portion will allow us all to get closer and maybe allow the next person to see how to achieve the next 10%.

PHP 5 is showing its progress at dealing with security, but like most good apps, it also relies heavily on the developer to use the tools properly.  PHP has always been a hacker-friendly languange, and there are not a lot of low level design tools to assist in this.  In this regard it allows poorly written apps to be built, but then so does any other language.

We have to judge it on it’s accomplishments with secure design inherit to the language. 

But we shouldn’t think any particular language is “out to get us”.  And this highlights the importance of not relying on any ONE language thinking it’s solutions are the best.  If that was the case we’d never have matured passed FORTRAN.  Maple is so much better to use.

Recently Visual Studio 9 was being released and as I uncovered from the opinionated source ‘eweek’, Peter Coffee mentions about this new developer tool:

I get a queasy feeling, though, from a combination of comments by Visual Studio Team System Lead Program Manager Jeff Beehler, who told us all on his blog last week that (i) “we’ve been fixing tons of bugs” and (ii) “we’re only fixing the most critical of issues to help prevent regressions.”

Does that give anyone else a sense of “uh-oh”? There’s plenty of room for debate about the precise behavior of bug discovery rates as the number of remaining defects in code shrinks down, but I don’t know of any model that estimates a sharp and sudden cutoff between “tons of bugs” and “good to go.”

 

Pasted from <http://www.eweek.com/article2/0,1895,1914426,00.asp>

So, yes in order to reduce costs (regressions) microsoft will concentrate on the critical issues.  No statement that they will fix them, just concentrate efforts towards them.

I too am skeptical about the cutoff point and where that occurs.  But that won’t change the fact that (i) it will happen and (ii) there will be issues and (iii) there will be supporters and defectors as a result. 

Oh I almost forgot, (iv) a holy war.

I’d normally start this paragraph out with ‘in conclusion’ or some such official closing remark, but is this really concluded?  Not by a long shot.