[Clipart] Site fixup work

[Bryce Harrington]

Kees and I worked on the site for a while today.  Kees reviewed and
reactivated all the scripts that looked like they were in use, and I've
fixed up a few other things.  Can the rest of you please look over the
remaining tasks and finish them up?  There's a few issues that neither
kees nor I could fix due to permissions or whatnot.  Thanks!

Bryce

On Sat, Oct 29, 2005 at 01:32:27PM -0700, Bryce Harrington wrote:
> Upload Tool
> ===========
>  1.  Implement security fixes for upload.cgi [jonadab]
>    + IMPORTANT:  Eliminate concept of "other" extensions from all upload
>      scripts.  See Appendix I at end of this message.
>    + Reject file types beyond the specific set we accept
>    + Check mimetype of uploaded files to verify the type matches the
>      extension; if not, reject file
>    + Move all .cfg files to /srv/clipart.freedesktop.org/etc/
>  2.  Which of the upload*.cgi files do we actually need?  (Remove the
>      ones that are not needed.)  [jonadab]
>  3.  Review Kees' security howto for other fixes needed, and plan
>      implementing them [jonadab]

>  4.  (DONE) Review submit.php for security vunerabilities [kees]

       -- submit.php had some bad security issues.  It appears to not be
          used anywhere though, so has been disabled.

>  5.  Install upload scripts back into cgi-bin [jonadab]



> Navigation
> ==========
>  1.  (DONE) Review the navigate script for vulnerabilities [kees]
>  2.  (DONE) Restore navigate script [bryce]

> Screenshot
> ==========
>  1.  (DONE) Review the view_screenshots.cgi script for vulnerabilities [kees]
>  2.  (DONE) Review the upload_screenshot.cgi script for vulnerabilities [kees]
>  3.  (DONE) Restore view_screenshots.cgi script [bryce]
>  4.  (DONE) Restore upload_screenshot.cgi [bryce]
> 
> 
> Security
> ========
>  1.  IMPORTANT:  Contact attacker's ISP (See Appendix II) [rejon]
>  2.  Create a CGI Security Howto [kees]
>    + Top 5-10 most common attacks to watch out for
>    + Best practices for handling uploaded files
>    + Best practices for untainting user input
>    + Best practices for handling CGI params
>    + Greppable things to look for in apache logs
>  3.  Place links to kees' security howto in cgi-bin/README [bryce]
> 
> 
> Wiki
> ====
  0.  (DONE) Review UseModWiki for updates & restore [bryce]
>  1.  (DONE) Install latest version of MediaWiki
>  2.  Migrate the old wiki content into MediaWiki
>  3.  Update navigation links to wiki pages as appropriate
>  4.  Revise mediawiki look and feel to match OCAL site
> 
> 
> Incoming Bins
> =============
>  1.  (DONE) Configure Apache to treat files in incoming/ as non-executable.
>      It should only recognize PNG, SVG, RDF, ZIP, and tarballs. [bryce]

       -- I tried doing this via .htaccess files but no go, so instead
       I've sent in a bug to freedesktop.org to impose the appropriate
       constraints on the incoming* dirs.

>  2.  (DONE) Restore the group and other read permissions for the incoming dir [bryce]
>  3.  Remove exec permissions from all files in all the incoming dirs []

       -- Probably not necessary as it won't do much good.  The upload
          scripts should be modified to use a umask that doesn't give
          exec permissions.

>  4.  Remove group/other write permissions for all past incoming dirs []

       -- jonadab, I think you will need to do this one

>  5.  Update release procedure to set old incoming dir permissions
>      securely [jonadab]

       -- Kees says we probably don't need to do the acl stuff for the
          incoming directory, and that we should set it up like /tmp
          with it world read/writable but with the sticky bit (+t) to
          prevent people from overwriting each other's files.

> WordPress
> =========
>  1.  Identify any security updates for our WordPress install [turnip]
>  2.  Apply security updates for WordPress, if any [turnip]
>  3.  Move wp-disabled to wp [turnip]
>  4.  Re-enable WP in index.php (see index.php-orig) [turnip]

Turnip, I think you said this was ready to go?  Go ahead and reactivate
it on the site.

> Feedback Form
> =============
>  1.  (DONE) Review contact.php for security vulnerabilities [kees]
>  2.  (DONE) Reactivate permissions on contact.php [bryce]
> 
> 
> Keyword Search
> ==============
>  1.  (DONE) Review keyword_search.cgi for security vulnerabilities [kees]
>  2.  (DONE) Restore keyword_search.cgi to cgi-bin [bryce]
> 
> 
> Other
> =====
>  * Remove exec permissions from files in tools-disabled/
>    [rejon, turnip, nicubunu], then rename to tools/
> 
> 
> Appendix I
> ==========
> Here is the cause of the problem Kees found, and how to fix it:
> 
>    } else {
>      $ext = $filetype; if ($ext eq 'other') {
>        ($ext) = $file =~ /[.](.*)$/; } # This can be greatly improved.
>      $outfile    = catfile($CONFIG{destination_directory}, "$t.$ext");
> 
>  Basically, you'll need to eliminate the concept of "other" extensions
>  from all of the upload scripts.  (They all have the same basic
>  vulnerability.)  You'll need to process only known extensions so that
>  .php or .cgi file (or other future things) can't be uploaded.
> 
> 
> Appendix II
> ===========
> Suggested wording for contacting ISP about attacker:
> 
> "Our site was compromised by X IP address on October 17th; please
> investigate the incident.  I doubt international computer intrusion is
> allowed in your User Agreement.  Thank you for your attention."
> _______________________________________________
> clipart mailing list
> clipart at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/clipart