"Some files and directories in your install are writable by the server" (not sure where to go from here)

You should review the file ownership and permissions of those files as compared to the users and webserver user of your host. For example, if your webuser is "www-user" and those files and directories are owned and writeable by that user then that could allow an attacker to write arbitrary files or code to those locations. To fix you might chmod or chown those file or directories. You may also need to review your host's documentation on webroot file and directories for details on how to change the permissions.

Setting this issue to "postponed" for more questions.

Find out the apache user or <?php echo shell_exec('whoami'); ?>.

This should be fine as in CentOS apache is run by nobody and needs write access to the files/ directory for caching and file uploads. Drupal.org recommends something like:

$ ls -la sites/default | grep files
drwxrwx--- 9 nobody example-group 4096 Jul 19 14:18 files/

In debian/ubuntu www-user would the the user that should own the directory.

Now this isn't what youd' get from:
chmod 2775 sites/default/files

But that's not going to give you the permissions described in the drupal.org page listed above.

What specifically is Security Review looking for? Some write permissions are usually required for Drupal sites, for caching if nothing else.

Would be good if the error message was clearer indicating exactly what should be done to improve the security of the files directory.

Here is what this check is doing http://drupalcode.org/project/security_review.git/blob/refs/heads/7.x-1.... and specifically http://drupalcode.org/project/security_review.git/blob/refs/heads/7.x-1..... In brief, it's looking for all files and directories that are writable with the exception of Drupal's files and private files directory and many VCS directories.

I do believe the messaging could be more clear, but it's difficult to write out what exactly should be done because those steps vary depending on the specifics of the web server. I welcome review of the current documentation and ideas to make it more helpful to more people.

Here's a patch to at least take a hack at being much more explicit in the failure messages.

Definitely a challenge with Windows/Linux. But really, the default is Linux, so I don't see why we can't give a chmod and include a link to the docs for more information.

Feel free to rip up the proposal. I did it quickly and it definitely needs to be cleaned up and standardized.

Thanks @mgifford! I think the tests failed only because the success/fail text is tested for, so the .test file would have been updated.

I feel strongly that mitigation recommendations are best explained on the individual help pages rather than within the failure strings. For some checks it's necessary to set some context and expectations before suggesting one course of action or another. I do think the text of the help pages could use work and even the individual success/failure strings could be improved, but I'd like to keep the result separate from the action of fixing. What do you think of that?

Here's a new patch which adds some of your text to the security_review_check_file_perms_help() function and holds onto the text added within the module writtten files.

Looks good to me. Thanks!

Committed. Thanks! http://drupalcode.org/project/security_review.git/commit/d00f853

As Drupal6 has been EOL https://www.drupal.org/about/drupal6-eol closing as outdated