The chronicles of the work and personal life of a boring software developer with an awesome dog.
Friday, June 6, 2014
Here's how to change the time zone in CentOS. This should work on both CentOS 5 and 6.
First, determine the correct timezone. You can do this using
tzselect (which just outputs some text and doesn't save anything), or by looking in
/usr/share/zoneinfo for the right file. I'm on Pacific time, so for me it would be America/Los_Angeles.
Now, back up your existing time zone file:
# mv /etc/localtime /etc/localtime.bak
Then symlink the desired zoneinfo file to localtime:
# ln -s /usr/share/zoneinfo/America/Los_Angeles /etc/localtime
Now if you run
date, the appropriate time zone should be displayed. There is one more step though. Open up the file
/etc/sysconfig/clock and edit it to reflect the appropriate zone. For example:
Without this change,
/etc/localtime will get overwritten and will revert to the previous time zone after yum or rpm updates tzdata.
Thursday, May 8, 2014
Annie and I have decided to take our love of photography to the next level and make it a career and a way of life — so far it has been going really well, and we've gotten lots of absolutely glowing feedback!
We're currently covering weddings and events around the San Francisco Bay Area, from San Francisco to San Jose and also the East Bay. Check out our website at ataleahead.com!
Thursday, March 20, 2014
Darktable's OpenCL isn't activated by default on Fedora when using the RPMFusion Nvidia drivers, apparently because Darktable can't find the library:
$ darktable -d opencl (...) [opencl_init] trying to load opencl library: '
' [opencl_init] could not find opencl runtime library 'libOpenCL' [opencl_init] no working opencl library found. Continue with opencl disabled [opencl_init] FINALLY: opencl is NOT AVAILABLE on this system. [opencl_init] initial status of opencl enabled flag is OFF.
A quick, if hacky, solution is to just make a symlink to Darktable's directory so it can find the library:
# ln -s /usr/lib64/nvidia-304xx/libOpenCL.so.1 /usr/lib64/darktable/libOpenCL.so
(Obviously, adjust the paths based on your system.)
Wednesday, December 4, 2013
Prosper Marketplace is one of the two big peer-to-peer lending platforms (the other being Lending Club), where individuals can loan or borrow money from each other. Like any online investment system, it provides a way for users to move money in and out via ACH transfers to regular bank accounts. And to do that, one needs to link one's Prosper account and bank account.
Since we're talking about a financial institution making important account changes, surely they have a secure way to do this, right? Wrong.
Back in March 2012 when I started making loans on Prosper, the process was pretty standard: enter the bank account number into Prosper.com (over HTTPS), wait a few days for some verification deposits of less than $1 each, and then log back into Prosper.com and type in the amounts to verify that you really own the bank account. This seems to work for most financial institutions, but apparently not Prosper, because, in a unique move that harms both security and usability, they've changed it. Now, when trying to add or remove a bank account, Prosper shows the following message:
For security reasons, to add or change your bank account, you must print a fax cover sheet and attach a copy of a cancelled check from the bank account you wish to add.
Click here to print a specially coded fax cover sheet which will speed processing. Specific instructions are printed on the cover sheet.
The instructions say to fax or email a copy of the account holder's driver's license and either a voided check or recent bank statement. And they won't accept this form snail-mailed or hand-delivered (I called to check). This is horrible!
Fax and email are both completely insecure methods of communication. Anyone between me and Prosper can read, copy, and store my driver's license, bank account number, address, and whatever other personal information I might be sending (like any recent transactions shown on the bank statement). Email is probably worse because typically emails are routed through a couple of servers, creating multiple copies along the way.
It's especially scary that Prosper's message begins with "for security reasons" — is their intent to eliminate security? Because that's the only effect on security that I can see. If there is any security benefit to this approach at all, I'd love to hear. Anyway, how can Prosper even verify whether a copy of a driver's license, check, or bank statement is legitimate? Copies of all of these items are trivially forgeable.
Worse, Prosper is requiring its lenders to send private documents over an insecure channel. One example attack, just for illustration, might be the following:
- Intercept a legitimate fax/email containing relevant documents. (Example methods: hack an insecure mail server along the route, hack a router, DNS attacks, routing attacks, bribe a Gmail/Hotmail/Yahoo employee, wiretap ...)
- Slightly modify the voided check or bank statement to show the same name, but an account number owned by the attacker.
- Send Prosper a new email containing the real driver's license with the modified check or bank statement.
- The victim probably doesn't notice since the "Bank Accounts" section of the Prosper site only shows the name of the bank and the last few digits of the account number; only the account number will have changed.
- Wait for the real user to withdraw some cash out of Prosper.
I am extremely disappointed that Prosper has taken such a giant leap backwards in terms of security and am strongly considering withdrawing my funds from the platform and leaving — if this is how their public-facing side operates, then what security nightmares are hidden from view?
Monday, May 20, 2013
It's tempting to assume that PHP's $_SERVER array mostly contains fields out of the reach of an attacker, since these are "server" variables. However, that's not always the case; in particular, the seemingly innocuous
PHP_SELF field can be a vector for cross-site scripting.
For example, consider the following
<form method="POST" action="<?php echo $_SERVER['PHP_SELF'] ?>"> <!-- ...form elements... --> </form>
If I visit
$_SERVER['PHP_SELF'] will be
/foo.php and everything will work correctly.
But what if I visit
http://www.example.com/foo.php/"><script>alert('hello');</script> instead? Then the rendered HTML will be:
<form method="POST" action="/foo.php/"><script>alert('hello');</script>"> <!-- ...form elements... --> </form>
This allows injection of arbitrary script running under the host site's context, also known as XSS. Two ways to fix this are:
$_SERVER['PHP_SELF']. The former is the name of the actual script file and can't normally be manipulated by an attacker.
- Use htmlspecialchars(), which by default will escape double-quotes and prevent a user-supplied string from breaking out of an HTML attribute context.
By the way, this was pretty surprising behavior to me for two reasons:
- The documentation of PHP_SELF is misleading: The first sentence says:
It seems odd that PHP would refer to something like
The filename of the currently executing script, relative to the document root.
/foo.php/"><script>alert('hello');</script>as a "filename."
- It's pretty bizarre default behavior that PHP will execute
/foo.phpfor a request of