create new tag
, view all tags
Various guides to the use of Perl's taint checking, such as the Secure Programming Guide, Taint Checking FAQ and perldoc perlsec, make it clear that you should always 'filter in' the legal characters for a particular value when untainting a variable. TWiki.cfg's $securityFilter adopts the opposite approach, meaning that it's easy to forget some character that should be blocked.

In addition, I've noticed quite a few places in the code where a value is untainted without checking it. This makes taint checking somewhat less useful, to say the least smile

I think we should go for a 'filtering in' approach, as part of improving the security of TWiki.

Another security issue that should be addressed is the use of system() with a single argument - since this can call a shell (and does, in some TWiki usage), this is not very secure and is one reason that taint checking is required. Using two arguments, with the first one being the pathname of the program, avoids this.

This is quite important for Internet sites, but is also an issue for intranets where an attacker might be able to use TWiki as a point of entry into a server. For example, it would be handy to use TWiki attachments to manage software downloads by customers, but it would need to be very secure to place it in the demilitarised zone (DMZ) of a firewall, i.e. exposing it to the Internet with relatively valuable contents.

-- RichardDonkin - 27 Apr 2002

Please do not scare me like that! smile I promised my boss that TWiki is safe, because many smart, security-aware programmers reviewed the code and made sure all security issues are fixed. It was exactly his point if TWiki does not have some TWiki-specific exploits, which TWiki-aware hacker may abuse.

What changes I need to do in standard TWiki installation? Can be changes you suggested above be included in upcoming BeijingRelease?

-- PeterMasiar - 29 Apr 2002

TWiki is probably reasonably secure, for the reasons you mentioned - e.g. it uses taint mode and generally tries to be careful about how it does things. However, there are some areas where this needs to be improved, particularly if you are going to put it on a high-profile Internet site, or on a webhost where all CGI scripts run as 'nobody'.

My comments are mainly based on 'good practice' security guidelines, and seeing a few questionable untainting actions in the code, not on knowledge of specific holes - this sort of continuous review of security is what the better OpenSource projects, e.g. OpenBSD, use to make sure they don't have holes. This probably looks a lot more scary because it is being discussed in an open forum - similar issues exist in commercial software but they are handled behind closed doors smile

-- RichardDonkin - 29 Apr 2002

We had some security reviews in the past and made changes based on that, so TWiki is already fairly secure. Nevertheless, there is always room for improvements!

TWiki's $securityFilter does not the 'filter in' because it is difficult to list all allowed chars, especially in an environment other than English. Once we have a good i18n we can switch over to the 'filter in' approach.

There are a few places in the code where a value is untainted without checking it, this is because it has been checked previously in the chain. Not pretty and is error prone, but it works. This should be fixed.

-- PeterThoeny - 30 Apr 2002

Thanks for the explanation - sounds quite reasonable, but there are some areas where filtering-in would be safer, particularly when handling URLs, e.g. in TWiki.pm at line 208 (TWikiAlphaRelease), the following code is potentially vulnerable. Since we have a limited set of characters allowed in topic names, I don't see a problem with just filtering in based on alphanumerics:

    # filter out dangerous or unwanted characters:
    $topicName =~ s/$securityFilter//go;
    $topicName =~ /(.*)/;
    $topicName = $1 || $mainTopicname;  # untaint variable
    $webName   =~ s/$securityFilter//go;
    $webName   =~ /(.*)/;
    $webName   = $1 || $mainWebname;  # untaint variable
    $includingTopicName = $topicName;
    $includingWebName = $webName;

-- RichardDonkin - 30 Apr 2002

Now that the InternationalisationEnhancements are done, we should be able to move to a more secure 'filtering in' approach as discussed above. This is also necessary for Unicode (UTF-8) support that doesn't break security, as discussed on InternationalisationUTF8. Volunteers welcome - check the PatchGuidelines and start submitting!

-- RichardDonkin - 11 Mar 2003

Just one (ignorant) question -- will this break those tricky little scripts that let us make changes on a host system that doesn't allow us root access? (Richard, I think you know the scripts I mean, as I think you suggested one to me once.)

-- RandyKramer - 12 Mar 2003

Scripts such as CGITelnet, mentioned in TWikiDebugging, aren't affected by TWiki code changes, so they won't be broken by this.

-- RichardDonkin - 14 Mar 2003

Umm, did I not just read that Perl is giving up hope of ever being sufficiently secure via taint analysis, etc.? (Cannot find the reference, but I swear I found it when reviewing Perl 5.6.1 or Perl 5.8 recently.) No serious secure system administrator would rely on Perl. It is better to use techniques such as Using Unix Groups For TWiki Security, and chroot boxes, if you want to go that far. Use Perl security as an extra level, to decrease the chance of a twiki server being taken down; but use OS security to decrease the chance of a security hole in TWiki or Perl bringing down the entire computer.

-- AndyGlew - 15 Apr 2003

Related pages: SecureSetup, SettingLibPath
Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2003-04-15 - AndyGlew
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.