• Firefox 3+
• SeaMonkey 2.0 (tested on 2.0a2)
• Flock 2.0
• Fennec 1.0 (tested on 1.0a2)
• Songbird 1.0

Fennec took a bit of fiddling because it’s not well documented yet. However, the code is available and that helped. Here are some screenshots of the fruits of my Fennec labor. A quick look shows that RequestPolicy is the 12th extension to add support for Fennec (RequestPolicy is the most popular experimental one).

I had never actually gotten around to trying Flock before, and that was interesting. I definitely see its value to a large number of social network-using and mucho media-viewing users.

As I describe it on the requestpolicy.com website:

RequestPolicy is a Firefox extension that improves the privacy and security of your browsing by giving you control over when cross-site requests are allowed by webpages you visit.

The lack of user control over cross-site requests is a fundamental area that has been overlooked in browser security. We have great extensions like NoScript to give us control over the execution of scripts and objects in our browser, but cross site requests are still a major privacy and security problem that has been neglected. RequestPolicy provides a strong and secure default policy (blocking cross-site requests) and lets you whitelist cross-site requests as needed. As with extensions such as NoScript, within a week of using the extension, you won’t need to do much whitelisting.

The current version is 0.3.4. You can download it from requestpolicy.com or you can get it from the Mozilla addons site (addons.mozilla.org, a.k.a. AMO).

I just nominated it for public status at AMO a few days ago. It will probably be somewhere between a few weeks and a few months before it makes its way through the public nomination queue. In the mean time, downloading from AMO requires registering an account there, but you can download it from requestpolicy.com if you don’t have or want an AMO account.

It’s important to remember that this isn’t a replacement for NoScript. A truly secure Firefox installation will include both RequestPolicy and NoScript.

Let me know if you have any questions or suggestions, and especially if you discover any bugs!

What all developers need to keep in mind are two things:

1) SSL does very little good unless you are talking to who you think you are talking to.

2) The communication library you are using may not be validating SSL certificates.

Regarding #1: Why does SSL do little good without certificate validation? It’s because having an encrypted conversation with a man-in-the-middle is not the idea. In that case, all you’re protecting against is someone snooping on the wire between you and the attacker you are having the SSL conversation with. In the day of BGP attacks and DNS cache poisoning, which I’m lumping together in the “MITM” category for these purposes, the MITM isn’t necessarily only a powerful entity like a government. These aren’t just theoretical risks.

Sometimes developers do this intentionally out of ignorance and convenience, like popular billing systems disabling certificate validation. (Side note: as far as I know, that company didn’t actually respond by making the default secure, instead they just buried a new option where you can enable proper SSL communication. Nice!) Other times, though, it’s not willful stupidity or intentionally putting users at risk, but rather just a lack of understanding of how SSL works and what the dangers are that SSL exists to protect against.

Related to understanding the purpose of SSL are the general arguments for better education about fundamental security topics (in schools, among employees, and by developers on their own), requiring an understanding of security fundamentals when hiring developers, and also recognizing that having security experts on your team is crucial because you can’t expect your developers to all be security experts.

Regarding #2: Often, though, developers are smart people who know the risks as well as the solution. They’re using SSL for the right reasons. It just, unfortunately, happens that they took for granted that other developers understood the same things and those other developers defaulted to correct security. When using a library that handles SSL, informed developers often assume that other informed developers wrote the SSL code. It makes sense. They assume that certificates are being validated by default. They assume that if the library can’t find the OS’s installed root certificates, that every request will fail and the developer using the library will then have to make sure that the code can find the root certificates available on the system. That’s the smart and expected behavior. However, the code we use was not always written this intelligently.

An example of this is python’s urllib. Many smart developers have written insecure code because they assumed if you use urllib to make an SSL connection, SSL will be used as it’s supposed to be. Instead, urllib as it was originally written and still currently exist ignores the fact that SSL is used for a handful of important reasons and just ignores security almost completely (and silently). It proceeds to retrieve any https-requested content with almost the same level of security as a plain http connection (because, really, when you are not validating SSL certificates, that’s basically what you have unless your adversary is someone passively listening with wireshark at the same café as you).

Many important projects have been bitten by python’s urllib SSL negligence. These includes Red Hat Enterprise’s update system, YUM, and Tor’s in-development updater. Thankfully, urllib will get better but not perfect in python 2.6.

What should you do? First, understand why SSL exists. Second, test any code you write that uses or might use https urls to ensure that that it fails when the SSL certificate isn’t valid.

Application: AWBS < 2.6.0
Severity: Highly Critical
Impact: Disclosure of sensitive information
Cross site scripting
Vendor Status: Vendor released version 2.6.0 to address issue. Testing still needed to verify that issue is corrected.

Vendor: Total Online Solutions, Inc.
App. Website: http://www.awbs.com/
References: http://www.justinsamuel.com/2007/06/10/awbs-magic_quotes_gpc-off-sql-injection-and-xss-vulnerabilities/

————————————————————————–

Description:

Advanced Webhost Billing System (AWBS) contains multiple SQL injection and XSS
vulnerabilities due to a lack of user input validation.

The software is not vulnerable to these issues when running with PHP’s
magic_quotes_gpc setting “On”. The vendor states that magic_quotes_gpc “On” is
a requirement in one place in their installation guide. However, this setting
is not checked by the installer nor is it enforced by having the software
refuse to run with magic_quotes_gpc “Off”.

These vulnerabilities allow for any user with an account in the AWBS software
to perform SQL injection in numerous places. This can be done even with new
accounts created through the public side of AWBS that have no active services.

The available SQL injection attacks can be used to mine all information from
the AWBS database. This includes the following information:

* Root passwords to all servers used for hosting the websites of hosting
accounts sold through AWBS, resulting in multiple server compromise.
* Root passwords to all dedicated servers sold through AWBS, resulting in
multiple server compromise.
* Control panel usernames and passwords for all hosting accounts sold through
AWBS, resulting in multiple website compromise.
* Credit card information for all customers whose credit card info is stored in
AWBS, even if the administrative option to encrypt credit cards numbers
has been used. The encrypted credit card numbers are not safe because the
symmetric encryption key can also be obtained from the database.

Additionally, SQL injection attacks allow an attacker to bypass AWBS’s anti-XSS
input validation. The available XSS attacks allow an attacker to compromise the
AWBS administrator’s session id to gain full administrative access to AWBS.

————————————————————————–

Proof of Concept:

Proof of concept exploit code has been provided to the vendor for every attack
outlined in the description.

————————————————————————–

Disclosure Timeline:

2007-06-10: Informed AWBS developers of vulnerability details by email.

2007-07-26: Public disclosure.

————————————————————————–

Recommendations:

Do not run AWBS with PHP’s magic_quotes_gpc setting “Off” until the vendor
releases a fix.

Application: AWBS < 2.6.0
Severity: Less Critical
Impact: Disclosure of sensitive information
Vendor Status: Vendor released version 2.6.0 to address issue. Testing still needed to verify that issue is corrected.

Vendor: Total Online Solutions, Inc.
App. Website: http://www.awbs.com/
References: http://www.justinsamuel.com/2007/06/10/awbs-dedicated-server-info-visible-to-all-users-vulnerability/

————————————————————————–

Description:

Advanced Webhost Billing System (AWBS) allows any user access to the details of
all dedicated servers sold through AWBS.

The information made available about all dedicated servers includes:
- Server hostname
- Main IP address
- Admin username
- Nameservers

————————————————————————–

Proof of Concept:

Proof of concept exploit code has been provided to the vendor.

————————————————————————–

Disclosure Timeline:

2007-06-10: Informed AWBS developers of vulnerability details by email.

2007-07-26: Public disclosure.

————————————————————————–

Recommendations:

If using AWBS to sell dedicated servers, remove the file smanage.php until the
vendor releases a fix or upgrade to patched version of software.

Vulnerability discovered by: Justin Samuel (www.justinsamuel.com)
Discovery Date: 2006-07-11
Severity: Less Critical
Impact: Exposure of sensitive information

Product: ModernBill
Affected Versions: 5.0.1
Vendor: ModernGigabyte, LLC (www.moderngigabyte.com)
Product Link: http://www.modernbill.com/

#################################################################

Update 2006-08-19:
Not fixed as of 5.0.4, despite vendor knowledge of the issue since 2006-07-12.

#################################################################

Vulnerability Description:

ModernBill’s CURL (a.k.a. cURL, curl) communication with credit card processing gateways is done with CURL ignoring any invalid SSL certificate of the host it is communicating with.

Specifically, the following have been set to FALSE for CURL communication:

CURLOPT_SSL_VERIFYPEER
CURLOPT_SSL_VERIFYHOST

The CURLOPT_SSL_VERIFYPEER setting of FALSE stops CURL from verifying the peer’s certificate.

The CURLOPT_SSL_VERIFYHOST setting of FALSE stops CURL from checking the existence of a common name in the peer’s SSL certificate.

#################################################################

Vulnerability Verification:

To check the CURL settings in use by ModernBill:

1) Install ModernBill.

2) Setup a payment processor.

3) In the file lib-modernbill/include/config/debug.php, change
define(“DEBUG”, 0);
to
define(“DEBUG”, 1);

4) Attempt to process a credit card through the ModernBill’s Virtual Terminal and look for the following in the debug output of the page:

[constantsSetting] => Array
(
[CURLOPT_RETURNTRANSFER] => 1
[CURLOPT_SSL_VERIFYHOST] => 0
[CURLOPT_SSL_VERIFYPEER] => 0
[CURLOPT_TIMEOUT] => 3000
[CURLOPT_CONNECTTIMEOUT] => 50
[CURLOPT_VERBOSE] => 0
[CURLOPT_NOPROGRESS] => 1
[CURLOPT_FAILONERROR] => 0
)

#################################################################

Exploit:

To exploit this vulnerability, an attacker would need to perform a Man-In-The-Middle (MITM) attack so as to receive the communication from ModernBill that was intended for the credit card processing gateway. This would include any variety of DNS attacks that would cause ModernBill to resolve the gateway’s hostname to the IP address of the attacker.

A successful attack would lead to the attacker having access to all credit card information that ModernBill attempts to process through the credit card processing gateway.

#################################################################

Solution:

Discontinue using ModernBill until they stop disabling fundamental security that is part of the SSL protocol.

#################################################################

* shared hosting security: removed posix functions [shared hosting security]
* removed pcntl functions [shared hosting security]
* added dummy domxml package [compatibility with other packages that depend on it, such as certain plesk 8 packages]

This build does have cgi compiled with fastcgi support.

Additionally, there is a corresponding php-apc 3.1.0 rpm available in the downloads section for this build of php.

To get these files with up2date, add my rpm signing key:
rpm –import http://www.justinsamuel.com/downloads/rpms/RPM-GPG-KEY.js.txt

And add this line to your /etc/sysconfig/rhn/sources:
yum justinsamuel-com http://www.justinsamuel.com/downloads/rpms/redhat/el4/en/$ARCH/js/

—
topics: rh4, rhel4, red hat enterprise linux 4, centos4, cent os 4, php5, apc

to use this, for example on a plesk box to allow domains to use sftp without having to give them a chroot’ed bash shell, do the following:

- install the scponly rpm from the downloads area
- add the following line to your /etc/shells file
/usr/sbin/scponlyc
- set any domain you want to have sftp access without any other shell access to use this shell.
- optionally, edit your domain templates and make the default shell this one and remove ability for clients to change the shell for a domain

note that this will only allow domains to use sftp but not scp (at least on a redhat box). this is because plesk decided to put the scp binary for a site’s chroot someone different than it exists in the rest of the system, and so it’s not where the scponlyc shell will look for it. so, just keep that in mind in case anyone complains sftp works but not scp.

if you want to have scp work for a domain, hard link the domain’s bin/scp to usr/bin/scp. if you want, you can even make the change to the chroot directory so that newly created domains have scp available, too. and if you’re brave, you can use the chrootmng tool to setup existing domains with your changes to the chroot directory.

Trying to enable APC for all sites on a server that has the sites running php though fastcgi (with a very low shm_size) resulted in odd behaviour on some sites. An shm_size of 3 or 4MB on a site running drupal produced errors of apc_sma_free: could not locate address, but 2MB seemed to work fine. Other sites handled the setting of 3 or 4MB just fine. I didn’t test any further as all i really needed to verify for myself was that enabling APC for all sites wasn’t a good plan. I’ll stick to turning it on in each sites’s php.ini for now for those that are very heavily trafficked.

mkdir /usr/share/ssl/certs/hostname.domain.com
cd /usr/share/ssl/certs/hostname.domain.com
(umask 077 && touch host.key host.cert host.info host.pem)
openssl genrsa 2048 > host.key
openssl req -new -x509 -nodes -sha1 -days 3650 -key host.key > host.cert
...[enter *.domain.com for the Common Name]...
openssl x509 -noout -fingerprint -text < host.cert > host.info
cat host.cert host.key > host.pem
chmod 400 host.key host.pem