This is a followup to a post by Drakino here.

I second the motion to reenable at least a subset of HTML code on the BBS. A thing I really miss is the ability to use random colors and font sizes. The other thing I really miss are tables. Both <font></font> and <table><tr><td> should be safe.
If HTML isn't reenabled, [img] needs a fix to allow any URL for the picture, without a check of the file extension or content. Or it should really accept any image format, be it GIF, JPG, PNG or TIFF. Also, a UBBCode implementation of tables is needed.

cu,
sven

Unfortunately, allowing HTML is either an "off" or an "on" proposition. You can't enable a subset. And the decision was made to turn it off. I think it was the right decision and I will stick with Paul on it.

If you wish for PNG graphics, font tags, and table tags to work in this BBS software, there's little that Paul can do about it. Perhaps post on the Infopop forums and ask the developers of the BBS software about these things.

Hi.

As it is commercial software, I guess it is Paul's task to bug them about new features. I am only using it a a end user, but am not running a copy of it by any stretch of imagination. Also I didn't pay for it. I am only making and seconding the wish some (I would even say _many_) others have already expressed: Reenable HTML in posts. I Just added alternative solutions I would recognize as being sufficient.
Honestly, I didn't see many problems (if any at all) with HTML in posts, but I have seen many problems since it was disabled. I know that there is a (theoretical) possibility of exploiting server and/or client bugs with HTML in posts, but as far as I know, no such attempt was made on this board until now. Also, UBBThreads bugs might still be exploited with HTML being disabled, and the same is probably true for browser side. So far, I don't really see a reason why it was disabled in the first place.

cu,
sven

It was disabled for security reasons.

Which is exactly what I think is either invalid, or also applies to UBBCode. Actually, since HTML is not parsed by the BBS software, while UBBCode needs to be parsed by it, it would be easier to hack the BBS software using UBBCode then it is using HTML. This, of course mainly applies to buffer overflow attacks, which are avoidable if the software is written The Right Way(tm).
If Paul and you are concerned regarding possible user side (browser side) exploits, this are almost certainly also doable using UBBCode.
If there is another security reason I overlooked, I would really like to know which it is (via PM if you don't want it out in the public).

cu,
sven

Which is exactly what I think is either invalid, or also applies to UBBCode. Actually, since HTML is not parsed by the BBS software, while UBBCode needs to be parsed by it, it would be easier to hack the BBS software using UBBCode then it is using HTML.

Yeah, this is why I never bought the original explanation that there was some kind of security concern here. HTML is a *markup language*. Unless it's carrying embedded client-side JavaScript or something, I find it difficult to believe someone can do anything more malicious than linking to www.goatse.cx or using <BLINK> tags.

(By the way don't click that link.)

Alternatively - html is one of the biggest security nightmares known to mankind
Currently, if you allow html in posts, you are effectively allowing control of the server, unless continous patching and hotfixing is done...and even then it won't be protected from some day-zero ish attacks.
At least limiting to UBBcode locks things down a lot. And it's the best you can do without a full time security person.

Hey, we can still link to sites/files and input text in some colours. It's not like we're stuck to 1 colour and no links

HTML is a *markup language*. Unless it's carrying embedded client-side JavaScript or something, I find it difficult to believe someone can do anything more malicious than linking to www.goatse.cx or using <BLINK> tags.

HTML was a markup language. These days it's a shell language for running client-side ActiveX controls and JavaScripts, all of which can take control of the browser in various eerie ways.

Presumably the BBS software never allowed unfiltered HTML to be entered into posts though; software with such a bug should never have left the building. [**] HTML that's filtered so that only certain tags (the genuine markup ones) are let through, and certainly not <script> or <object>, should be safe. Although see http://utter.chaos.org.uk/~pdh/test/ for what amounts to a "denial of service" attack, using just <table>, mounted against Netscape 4's table layout engine.

Peter

[**] Slight tone of sarcasm, as Outlook Express, among many others, clearly left the building with this bug in.

What the heck are you talking about??? By day I'm a developer of web server security software and I'd really love to know what in HTML allows you to "take control of a server!" Yes, running a web server is risky business because of CGI's, etc. which, if improperly configured, could allow a Bad Person (tm) to do Bad Things (tm) to your beloved web server. But tell me how allowing HTML to be added to BBS posts can "allow control of a server!" I'm serious, knowing this could give me a big raise at work!

And Peter, none of those table examples crash my browser. They might not get rendered properly, but they certainly don't constitute "denial of service" except for poorly written browsers. And the server could always check for too many nested tables when entering posts and complain. Besides, that's more of a client thing, the way people are talking here, you'd think every web server which displayed HTML was a wide open backdoor to root the server. How the hell do web site providers which allow users to upload HTML files stay in business then?

except for poorly written browsers

Phew, we're all safe then.

Actually, that page is pretty old, and modern versions of both Netmoscapezilla and IE are more robust.

Besides, that's more of a client thing, the way people are talking here, you'd think every web server which displayed HTML was a wide open backdoor to root the server.

Oh, I completely agree. No sanely-configured server is at server-side risk from HTML. But unfiltered HTML does pose client-side risks, and perhaps frog51 is thinking of regularly-insanely-configured servers?

Peter

Phew, we're all safe then.

Actually, that page is pretty old, and modern versions of both Netmoscapezilla and IE are more robust.


That's what I was getting at. There aren't many secrets left in HTML anymore. And yes, there are client-side risks associated with running unsafe content, be it JavaScript, Java applets, ActiveX controls, etc. But frog51 was basically saying that any HTTP server serving HTML content was at risk for some kind of exploit where one could "take over" the server, and my several years of experience as a netcentric security software developer tells me otherwise. But if such a thing in HTML existed, I would love to know about it so I can make sure my company's servers are protected from it!

Ah - it comes down to "properly configured", and "well written applications." As part of my job I, not to put too fine a point on it, hack companies as part of security audits, and as yet my team has rarely seen a well configured server, from a security standpoint. To reduce security further, allow the web server to display user-defined data (ie stuff you've posted.) The problem isn't so much html, as the fact that you can break the web server or the browser by giving them malformed strings or unexpected data. For a very simple example which most people should have patched anyway, see the Nimda worm. This wasn't exactly an html issue, but the html request broke server security. Malformed data strings in the URL are pretty easy to watch for, but how is the UBBcode going to spot malicious data in a posting? It ain't clever enough. It wil try to display it - leading to potential data disclosure or server attack.
For tools and exploits see astalavista.box.sk, but be warned - a lot of the sites listed there will actively try to attack your browser so protect yourself.

But tell me how allowing HTML to be added to BBS posts can "allow control of a server!"

If the bbs software doesn't correctly filter javascript and vbscript from any HTML posted to it then it is indeed possible to get access to server functionality that you shouldn't be able to get to.

It works like this:

• I post some HTML in a message to the BBS, with some carefully crafted javascript or vbscript embedded in it
• the BBS admin opens up the message
• the BBS software has failed to filter my script out properly
• my script gets to run
• my script is now running in the admins browser and therefore with all the admin's rights
• my script then gets clever and manages to access the BBS areas that are off limits to me normally (this bit is much easier to do if MS XML is installed on the admin's machine as I can then make arbitary calls against pages on the bbs easily, complete with the admin's cookies)
• if the settings on the admin's browser are sloppy enough then I can also mess around with data on their machine (the same applies to other user's machines too)
  

If I am very careful then all of this could happen without the admin being aware that anything is amis.

Now, this does all rely in everything being in place on both the server and the browser, the attacker having good knowledge of the BBS code etc

However this stuff is entirely possible, similar attacks have been demonstrated on public systems before (both Amazon and Yahoo had lousy script filtering at one point).

I have demonstrated such an attack on several intranet apps at places I have worked, so this stuff can be a real security risk.

Unfortnately filtering out the script while leaving the HTML intact can be quite difficult to get working 100%, so given that the BBS code was not written by Paul and so he couldn't trust it 100% I think he probably took the right desision to turn HTML markup off. The intranet apps I mention above (which are sold to third parties) now do not allow HTML markup in any data posted to them.

Okay I know exactly what you're talking about regarding malformed HTTP requests because I write web server plugin software which could be subject to such attacks (were I not such a talented programer, that is. ). But your terminology is a little misleading, because it wasn't an "HTML request" that broke servers using Nimda, it was an HTTP request. HTML is just the content of an HTTP *response* from the server. Those vulnerabilities have *nothing* to do with HTML, they have to do with a web server (IIS in this case) which was poorly written.

I realize that "poorly written" software is everywhere (buffer overflow vulnerabilities especially) but to say that HTML is somehow a server-side security risk is just not correct. And to clients, the only real risk is in non-HTML goodies like JavaScript and ActiveX, which can be very easily filtered.

Hence I'm not sure why HTML isn't allowed around here, although it does prevent l4m3rz from posting in 72 point font.

I post some HTML in a message to the BBS, with some carefully crafted javascript or vbscript embedded in it
the BBS admin opens up the message
the BBS software has failed to filter my script out properly
my script gets to run
my script is now running in the admins browser and therefore with all the admin's rights


Oh, okay, well as a security guy, the first thing I note in your complex scenario is that the admin is running software (in this case his browser) with a priveleged account on the same server that the BBS is running on. I can stop reading, because at that point anything can happen. That's asking for trouble. Besides, the default security settings in Netscape and IE don't allow for most of the things you're talking about to happen, they'd have to explicitly be turned to the lowest setting, which, if I'm not mistaken, is called "Please, Oh Please Do Bad Things to My Computer."

I'm not trying to trivialize good security practices, because I know some of this stuff isn't easy to remember and is sometimes a pain in the butt to follow. And yes, it's easier to just disable HTML markup rather than worry about what demons might be lurking in the PHP product's HTML filtering capabilities... But your scenario really relies on the administrator running a client program with permissions to do bad things to the web server... To that, I say "you reap what you sow."

And to clients, the only real risk is in non-HTML goodies like JavaScript and ActiveX, which can be very easily filtered

I have to disagree with this. It is easy to filter out the obvious forms of JavaScript and VBScript embedding, but due to the flexiblity of the browsers (particularly IE) it is difficult to filter out all the various ways that that script can be embedded and executed.

With our intranet apps that I have mentioned before we had to give up in the end with attempting to filter out script. We would keep thinking we had picked up all the cases and then one of us would come up with another crafty method to sneak some script in and get it executed.

Oh, okay, well as a security guy, the first thing I note in your complex scenario is that the admin is running software (in this case his browser) with a priveleged account on the same server that the BBS is running on.

No, that wasn't what I was saying. He does not need to be running the browser on the server at all.

Once my script is running in his browser on his local machine I can probably then access most of the features of the bbs that he has access to. At this point my script probably only has to do enough to grant my account admin rights and then me do the rest of the comfort of my own machine.

I have achieved attacks like this on software before, where the browser is running on the admin's local machine and IE is at the default security levels.

Are there really people who are stupid enough to execute untrusted scripts while holding admin privileges? (and are still allowed to be admins!)? Ouch.

Are there really people who are stupid enough to execute untrusted scripts while holding admin privileges?

You clearly haven't followed what I am talking about. I am not talking about an admin going off and deliberately running some untrusted script.

I am talking about them unknowingly running a bit of hidden script via the normal process of using the browser based internet app (in this case a bbs). By inserting a cleverly crafted bit of script into a post to the bbs, if the bbs doesn't successfully strip this script, this bit of script can get run when the admin views the post on the bbs. The admin would not even need to know that there was any script there.

I'm getting bored this this. It is possible to trick some webserver-browser based apps into accepting script that later gets executed on other people's browsers without their knowledge or interaction. It is possible for this script to then interact with the webserver application in question and carry out most actions that the user could, as that user. It is non-trivial to strip out all possible script from HTML while leaving the HTML intact.

I am not saying any of this is likely to happen on this BBS and it requires a very good knowledge of how the browsers and the web app in question works, but it is all perfectly possible. I have done it before on systems I have been auditing for security issues.

Scripts only get run if you configure your browser to do so, don't they?

I certainly can't imagine wandering around the Web or even this BBS with such insecure settings...

Um, yeah. What Andy said.

By defauly, buth IE and Netscape run Javascript, and IE runs VBScript on it's own by default. Security warnings might pop up if it tries to install anything, or do things beyond the sandbox. Normally when I worked with Javascript, it has severe limitations on what data it could work with as a security precaution. Who knows how tight IE follows those rules though.

If the BBS dosen't currently support stripping dangerous code out, it should be suggested by Paul, as he is the registered user of the software. It should be non trivial to add, and secure enough to enable HTML code again. Everyone takes a risk by connecting to the internet, web sites can only go so far. Beyond that, it's the users responsibility to either apply the 30 patches a month to IE, or find a different browser.

And the only server vunerability known for UBBThreads was fixed in this version (5.5). And it was usable even with HTML code off.