Should security holes be patched?

[orange]

Now, if a security hole in the board software is discovered by somebody external to the project, of course it should be fixed as soon as possible.

What I'm talking about is when a security bug is found by one of the YSE team, and then a new version is released to fix it.

The problem being that since the software is open source, when a security fix is released, it's easy to see what the change was - and hence how the older version was vulnerable. This then makes it relatively easy for people to create a method of hacking older (unpatched) boards.

This then creates an urgency with which every forum admin needs to install the new version ASAP if they don't want to be targetted by script kiddies.

So what I'm really thinking is - is it safer just to keep any discovered security problems under wraps, but with a patch written which could be released if people in the 'wild' discovered the bug?

Obviously this is a bit of a no-win situation though, because if you didn't release the patches you'd be accused of distributing vulnerable software.

Just a few thoughts.

[haaseg]

My viewpoint is that probably script kiddies are going to be aware of a vulnerability much faster then the general public - they actively go out looking for those kinds of thing.  So when you find a security whole and make an update, you're really racing to let everyone else know before the script kiddies spread it around.

There is also a bit of covering your liabilities.  If you find a hole and publish a fix, and an admin doesn't update his code and gets his site hacked, then the admin really can't blame anyone but themselves.  If there is an unknown hole, the admin can charge that you knowingly distributed bad code, but wouldn't have much of a case.  However, if that admin were to find out that you *knew* about a security hole and did nothing about it, then you could be in hot water.

When you think about it, this is really one of the things that OpenSource is all about.  A couple of months ago, they discovered a fairly severe security hole in the SSH libraries for Linux.  Everyone was completely open about the find, and literally ever major Linux distrobution had a fix within 12 hours.  Where-as you report a secuity whole to a private company like Microsoft and a lot of times they just ignore you...  sometimes it takes months for them to send an update.  This even happens when someone publically publishes an MS vulnerability.

Also, disclaiming what the security hole was and how it was fixed leads to better security for the community as a whole.  If you were a developer for some PHP project, wouldn't you want to know exactly what the hole was and how to fix it.  It would be stupid to withhold that information and let serious issues propogate through various scripts.

[David]

Thanks for your thoughts, all feedback really is apreciated.

In the case of what we patched in 1.5.5 it was reported to myself and Jeff the day before yesterday so this was not something that was found internally.  This had actually, we believe, been exploited on the reporter's forum thus really demanding a patch.  I personally would rather see a patch and then the mad rush to patch then no patch and a few forums getting exploited.  I run a few linux servers and I have been on the other end of this too, the rush to patch really does suck but I have just accepted that it is part of running a server.  I think as long as we provide notification about a new patch, easy upgrade path, and support we have chosen the best option.

[orange]

Oh I'd definitely agree with that - if a hole is being publicly exploited, it really needs to be patched ASAP and all admins will just have to accept that as part of running the board.

And haaseg makes a good point about the legal ramifications of not making a fix public.

The reason I brought this up was that the new release reminded me of how a while back a friend was on holiday when a new version was released (I think it was 1.5.2 or something), and his board got hacked before he returned from holiday to patch it.

If it was a publicly found bug then that's just his bad luck; but if it was an internally found bug where the hackers based their attack on the patch, then his board would probably have survived if the patch had not been released.

I do understand though that obviously any bugs that there are in the code could be discovered by anyone and then exploited at any time, so the current method is probably the best. It's a shame that with the web there's no way to do a Windows-style Automatic Updates thing to download and install security patches automatically.

[[Unknown]]

That hole was begging to be found, if I remember right.  We have to weigh the severity along with it, because someone *will* find it.

Then again, I know at least one way, very very complicated way, to hack a YaBB SE forum.  It takes very specific circumstances, and no one will probably ever find it.... so I don't WANT to patch it, because it would only cause problems to do so. (and, like I said, it barely ever would work.)

-[Unknown]

[Fizzy]

The bottom line,

If there was a security hole and the Team did nothing to inform me of that problem, I then got hacked and my whole forum was trashed, I reckon I would be pretty pissed off by the fact that I wasn't told.

That would be an act of negligence.

I reckon the team are spot on - If there's a gap and it's practical to plug it - plug it.

[SnowCrash]

Btw... the hole that 1.5.5 fixed was published on BUGTRAQ a few hours ago...

[David]

Btw... the hole that 1.5.5 fixed was published on BUGTRAQ a few hours ago...

Thanks for letting us know Chris, now the patching madness becomes even more fun.  

[SnowCrash]

Thanks for letting us know Chris, now the patching madness becomes even more fun.  

psssssssssssssssssstttt! i'm incognito!

and btw... all holes on bugtraq become widely known among script-kiddies very fast... so i think that its not that bad to mention bugtraq here....

and adding a simple

$ID_MEMBER = intval($ID_MEMBER); 

to SSI.php (of course it must be added at the right place) fixes this issue... even if someone doesn't want to install the 1.5.5 patch....

[David]

The intval actually doesn't fully patch this vulnerability, thus I would not reccomend it.  It does however patch the vulnerability posted on Bugtraq.

[SnowCrash]

I don't know... I hadn't got the time to analyze the 1.5.5 mod... I just saw the BT-article...

I hope that SMF finally does ensure that passed parameters have the right data-type and that this totally (insert some "nice" words here *g*) way of handling POST/GET variables was changed... (i mean this slightly ... uhmmm ... "not so good" ... idea in index.php:

Code Select Expand

$types_to_register = array('GET', 'POST', 'COOKIE', 'SESSION', 'SERVER');
foreach ($types_to_register as $type) {
   $arr = @${'HTTP_' . $type . '_VARS'};
   if (@count($arr) > 0)
      extract($arr, EXTR_OVERWRITE);
})

I really hope that SMF is always just using and importing those variables that are really needed in a certain situation....

[[Unknown]]

I use casting a lot in SMF.  I prefer the (int) method because it is faster than intval(). (it just chops the variable, it doesn't bother with trying to interpret it.)

As well, no register globals emulation is used.  Instead, $_* is used.  But you know this.
Variables are never "imported" - I think this is generally unrecommended behavior.... it's just asking for trouble.

And yes, I agree... that was one of the things I didn't like.  Probably one of the things I spent the most time on was making everything use $_* instead.

-[Unknown]

[jack-uk]

Unknown, I think your logic here is very flawed.

I cannot criticise for not having time to fix a problem, but I think it is extremely irresponsible to refuse to fix security problems in the current version of the software.

We come at this from opposite viewpoints - you as a developer, and me from the security standpoint (it's what I do for a living I'm afraid).

It has been proved time and time again that 'security through obscurity' does not work. Security cannot be enforced by keeping aspects of the process a secret.

Your attitude of 'Only I know how to exploit this problem' smacks of arrogance and is a very Microsoft-esque stance - there are hundreds of skilled people out there who may have already found that hole, just like they discover holes in Windows, IIS (& any other package you care to mention) even though they (usually ) keep their source-code a secret. Access to the source makes such analysis easier and quicker.

OK, you may not have the time to do anything about this, but there are loads of dedicated, skilled and trustworthy programmers in the YSE community. Isn't it possible to enlist the help of one or two others who do have the time to correct the problem & share your findings?

With regards to the problem that was consigned to a private forum  recently, the information is already public - it's posted on securityfocus and loads of mailing lists .. along with full details that will enable me to protect my boards. I'd far rather be part of the stampede to safety than have my head in the sand when disaster strikes.

[[Unknown]]

Jack, there are so many possible holes in YaBB SE it's not funny.  The more fixes that are released, the more older versions will be hacked.  That's how the internet works; face it.

I have already given, actually a month and a half ago, a fix (and a better one than anyone has offered!) for the known vulnerability to the rest of the team.  However, I also told them that I was through with it - especially because the reporter waited until the very day after 1.5.5 was released to report it - and if you guys want to play follow the goat around, you can go ahead and do so.

To me it is rediculous, and there is very little possibility that there are not more holes in YaBB SE as far as I am concerned.  The one hack I found is so very very very very involved, and takes so very very very very many steps, no script kiddie is ever going to be able to find it.  they just won't, it would take them weeks to figure it out even if I told them where to look.

This isn't security through obscurity.  I didn't write the security of YaBB SE, and I have never liked it's method of security.  I did however write the security in SMF, and I can assure you that pretty much every hole for YaBB SE you could find would be a non-issue in SMF's code.

-[Unknown]

[jack-uk]

The more fixes that are released, the more older versions will be hacked.  That's how the internet works; face it.

That's why it is the responsibility of individual people to ensure that they keep their systems up to date. I know it doesn't happen as much as it should (see how many machines are still vulnerable to blaster, slammer and even code red)

I have already given, actually a month and a half ago, a fix (and a better one than anyone has offered!) for the known vulnerability to the rest of the team.

Then what is the problem with releasing it? I feeel very vunlerable knowing that there's known, fixable problems with the software and not being able to do squat about it.

To me it is rediculous, and there is very little possibility that there are not more holes in YaBB SE as far as I am concerned.

True, there are errors in every non-trivial piece of software. The trick is to deal with those errors as they are discovered. YSE 1.5.5 isn't an 'old' version of the software, it is the current version - and will remain so until YSE is declared 'dead'. If the problem was discovered in 1.4 and doesn't occur in 1.5, then it is the responsibility of those still running 1.4 to either fix the problem themselves or upgrade.

no script kiddie is ever going to be able to find it.

ISTR Microsoft making that exact same claim, and L0pht proving them very, very wrong

"That vulnerability is completely theoretical."
-- Microsoft
"L0pht, making the theoretical practical since 1992."

This isn't security through obscurity.

Sorry, that is precisely what security throough obscurity is - hopeing that something is well hidden enough for others to not spot it.

I didn't write the security of YaBB SE, and I have never liked it's method of security.

I appreciate that, but that isn't the argument - I'm not attacking the quality of code in YSE, I'm attacking the decision to leave your users running software with known security holes, with known fixes and not publishing said fixes.

I did however write the security in SMF, and I can assure you that pretty much every hole for YaBB SE you could find would be a non-issue in SMF's code.

Glad to hear it - will fixes be made available for any problems that are found?