16 Jan 2013
•
General
•
Mobile
I just released Pilot SSH, a server administration application for iPhone. So, why another SSH application? Aren't there dozens of these already?
I tried a lot of those shell applications, and they felt clunky on a phone. They are fine with a tablet (even more if you use a bluetooth keyboard), but writing commands on a phone's keyboard is not really intuitive. Moreover, the small screen of a phone is not really usable to display the command results.
But I reaaaaally wanted to manage my servers from my phone. Because I am not always in front of my computer. Because I am too lazy to get the laptop from the bag, open it, plug the 3G key or find WiFi, connect over SSH and type a command to restart a crashed web server. Because it would be awesome to be in a bar and say "hold on, I have update my server", open my phone and do it in 3 touches.
So, here it is, Pilot SSH, in all its glory, can out of the box:
- display running processes, the memory they use, and kill them
- show which websites are enabled or disabled in Apache
- display the uptime, halt or reboot the server
- show Apache logs
Pilot SSH process list
But there is more! The application is completely extensible, because it uses scripts stored on the server side, in your home, in ~/.pilotssh. You can totally replace the current scripts, download more from the Github repository, and make your own! The scripts can be written in any language, as long as they return a JSON string conforming to the API.
I already got a contribution soon after the launch, with a script to flush the caches. And I have a lot of ideas for new scripts:
- upgrade a Wordpress website
- display the status of processes managed by Monit
- create/remove users
- Support nginx too
- Display more logs
This is just the beginning, and I expect a lot of impressive ideas from the users of Pilot SSH. I can't wait to see them!
Do you want to try Pilot SSH? Everything you need is on its website!
Here is a small idea that I would like to throw into the world: most web applications use only one database user for most operations (installation, administration, common usage). Couldn't we harness the database to protect a bit your data?
How to
This is how you could do it:
- Create one user (called 'user') with full privileges on the database
- Create another user with no privileges (let's call him 'read')
- Create a copy of wp-config.php that you will name wp-config-admin.php
- Write the 'read' credentials in the wp-config.php and the normal credentials in wp-config-admin.php (don't forget to use different auth, secure auth, logged in and nonce keys)
- Create a copy of wp-load.php that you will name wp-load-admin.php
- Replace in wp-load-admin.php the reference to wp-config.php by wp-config-admin.php
- Replace in wp-login.php and wp-admin/* the references to wp-load.php by wp-load-admin.php
- Now, you can use the admin interface, create posts, etc.
- Grant some permissions to the 'read' database user: GRANT SELECT ON `db`.* TO 'read'; GRANT INSERT, UPDATE ON `db`.`wp_comments` TO 'read';
That was a bit of work, but not that hard! So, what did we do here? We created a user for the admin interface with full privileges on the database (create/update posts, change the taxonomy, approve the comments, etc) and another one for the front end interface, with only read privileges on all tables (that bothers me too, but read on).
This means that SQL injections, either in plugins or in Wordpress code (out of the admin panel) will be much harder to implement with this setup. Beware of the custom tables for some plugins. Those will require specific permissions. Depending on the plugin, some could be read only for common usage.
Going further
That's nice, but not enough in my opinion. As I said, the full select permission for the 'read' user bothers me. Couldn't we restrict a bit the permissions on wp_users? Some of the columns are needed, but do we need to access the user_pass column? Also, the "ALL PRIVILEGES" for 'user' is a bit too much. Do we really use the "FILE" privilege (out of SQL injections :D)?
Without further ado, here are the SQL commands you should use:
GRANT SELECT, INSERT, UPDATE ON `db`.`wp_comments` TO 'read';
GRANT SELECT ON `db`.`wp_commentmeta` TO 'read';
GRANT SELECT ON `db`.`wp_links` TO 'read';
GRANT SELECT ON `db`.`wp_options` TO 'read';
GRANT SELECT ON `db`.`wp_term_taxonomy` TO 'read';
GRANT SELECT ON `db`.`wp_usermeta` TO 'read';
GRANT SELECT ON `db`.`wp_terms` TO 'read';
GRANT SELECT ON `db`.`wp_term_relationships` TO 'read';
GRANT SELECT ON `db`.`wp_postmeta` TO 'read';
GRANT SELECT ON `db`.`wp_posts` TO 'read';
GRANT SELECT (user_activation_key, id, user_login, user_nicename, user_status, user_url, display_name, user_email, user_registered) ON `db`.`wp_users` TO 'read';
REVOKE ALL PRIVILEGES ON `db`.* from 'user';
GRANT SELECT, INSERT, DELETE, UPDATE, CREATE, DROP, ALTER, INDEX ON `db`.* TO 'user';
With these commands, 'user' can only manipulate tables. If you're an evil DBA, you can even revoke the "CREATE, DROP, ALTER" permission after install, and reactivate them only for upgrades or plugin installation. The 'read' user has the same permissions as before on wp_comments, has "SELECT" on all tables except the wp_users. For wp_users, we grant "SELECT" on all columns except the user_pass one.
Thanks to this configuration, even a SQL injection in a plugin will not reach the password hashes! We also removed dangerous permissions like "FILE". I'd like to prevent timing attacks like "SELECT BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'));" but i did not figure out what is the right syntax for this (I tried variations around: "revoke execute on function benchmark from read", without result).
Thankfully, WordPress mostly works with this configuration, and I think that a lot of other applications could be protected like this. Imagine: you could grant insert but not select on the credit card table in an e-commerce application, and process transactions with a background task with the right permissions.
Database privileges are indeed a powerful tool to protect your code from SQL injections. They might require some architectural changes, but the profits can be huge for your security.
As you can see, we are doing a KickStarter for the Windows 8 (WinRT) port of VLC media player. The goal is to take our existing code, which already works on Windows 8's "desktop mode", and make it run on WinRT, the "Metro" interface.
Porting code to WinRT offers significant challenges, mainly caused by the changes in the APIs. A lot of functions we were using, like LoadLibrary, are not available anymore, and replaced by slightly different functions (like LoadPackagedLibrary). Those might not be too hard to integrate into our current code base.
Other APIs, like sockets, were replaced by their COM interfaces counterpart (for instance Windows.Networking.Sockets). They are used to provide asynchronous interfaces for code running under WinRT. They got inspiration from mobile applications and the "always responsive" goal: a WinRT application should not use blocking code, and should go to sleep or wake up quickly if needed. With COM interfaces, the code polling the socket is executed in another process, and the data is provided through a callback. This changes a bit the usual networking code (connect->select->read->select>...) and we need to write a large layer of compatibility code.
After all of that, we still have to solve the issue of packaging. We already experimented a bit with side loading, which offers an easy way to distribute applications, but the real goal is to push VLC media player to the Windows Store.
So, why are we doing this? Windows 8 is happening, it is now preinstalled on most of the new computers.
Why am I excited to work on this port? This KickStarter will give us the opportunity to work full time on WinRT for a few months, and solve all these challenges for us, but also for other open source projects. We already know how to create a compatibility layer for different operating systems, so we will be able to build one for WinRT. We could also come up with guidelines on using free software toolchains to build WinRT applications.
Basically, we're paving the way to WinRT for opensource libraries and applications, with the nice side effect on running VLC on Windows 8.
Help us make this project a reality! Please contribute to our Kickstarter for Windows 8!
Adding push support to an Android app is quite easy, but it can be cumbersome to test it if the server part is not ready yet.
For this, you only need your API key, and the registration ID for your device (you can get it from a call to GCMRegistrar.getRegistrationId). Also, you should have already called GCMRegistrar.register from your app, with your sender id.
Then, to send a push message to your application, use this code:
import java.io.IOException;
import com.google.android.gcm.server.*;
public class Main {
/**
* @param args
*/
public static void main(String[] args) {
String apiKey = "...";
String deviceId = "...";
Sender sender = new Sender(apiKey);
Message message = new Message.Builder().addData("data1", "hello").build();
try {
Result result = sender.send(message, deviceId, 2);
System.out.println("got result: "+result.toString());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
Somebody just told you about a vulnerability in your code. Moreover, they published a paper about it. Even worse, people have been very vocal about it.
What can you do now? The usual (and natural) reaction is to downplay the vulnerability, and try to keep it confidential. After all, publishing a vuln will make your users unsafe, and it is bad publicity for your project, right?
WRONG!
The best course of action is to communicate a lot. Here's why:
Communicate with the security researcher
Yes, I know, we security people tend to be harsh, quickly flagging a vulnerable project as "broken", "dangerous for your customers" or even "EPIC FAIL". That is, unfortunately, part of the folklore. But behind that, security researchers are often happy to help you fix the problem, so take advantage of that!
If you try to silence the researcher, you will not get any more bug reports, but your software will still be vulnerable. Worse, someone else will undoubtedly find the vulnerability, and may sell it to governments and/or criminals.
Vulnerabilities are inevitable, like bugs. Even if you're very careful, people will still find ways to break your software. Be humble and accept them, they're one of the costs of writing software. The only thing that should be on your mind when you receive a security report is protecting your users. The rest is just ego and fear of failure.
So, be open, talk to security researchers, and make it easy for them to contact you (tips: create a page dedicated to security on your website, and provide a specific email for that).
Damage control of a public vulnerability
What do you do when you discover the weakness on the news/twitter/whatever?
Communicate. Now.
Contact the researchers, contact the journalists writing about it, the users whining about the issue, write on your blog, on twitter, on facebook, on IRC, and tell them this: "we know about the issue, we're looking into it, we're doing everything we can to fix it, and we'll update you as soon as it's fixed".
This will buy you a few hours or days to fix the issue. You can't say anything else, because you probably don't know enough about the problem to formulate the right opinion. What you should not say:
- "we've seen no report of this exploited in the wild", yet
- "as far as we know, the bug is not exploitable", but soon it will be
- "the issue happens on a test server, not in production" = "we assume that the researcher didn't also test on prod servers"
- "no worries, there's a warning on our website telling that it's beta software". Beta means people are using it.
Anything you could say in the few days you got might harm your project. Take it as an opportunity to cool your head, work on the vulnerability, test regressions, find other mitigations, and plan the new release.
Once it is done, publish the security report:
Warning your users
So, now, you fixed the vulnerability. You have to tell your users about it. As time passes, more and more people will learn about the issue, so they might as well get it from you.
You should have a specific webpage for security issues. You may fear that criminals might use it to attack your software or website. Don't worry, they don't need it, they have other ways to know about software weaknesses. This webpage is for your users. It has multiple purposes:
- showing that you handle security issues
- telling which versions someone should not use
- explaining how to fix some vulnerabilities if people cannot update
For each vulnerability, here is what you should display:
- the title (probably chosen by the researcher)
- the security researcher's name
- the CVE identifier
- the chain of events:
- day of report
- dates of back and forth emails with the researcher
- day of fix
- day of release (for software)
- day of deploy (for web apps)
- the affected versions (for software, not web apps)
- the affected components (maybe the issue only concerns specific parts of a library)
- how it can be exploited. You don't need to get into the details of the exploit.
- The target of the exploit. Be very exhaustive about the consequences. Does the attacker get access to my contacts list? Can he run code on my computer? etc.
- The mitigations. Telling to update to the latest version is not enough. Some users will not update right away, because they have their own constraints. Maybe they have a huge user base and can't update quickly. Maybe they rely on an old feature removed in the latest version. Maybe their users refuse to update because it could introduce regressions. What you should tell:
- which version is safe (new versions with the fix, but also old versions if the issue was introduced recently)
- if it's open source, which commit introduced the fix. That way, people managing their own internal versions of software can fix it quickly
- how to fix the issue without updating (example for a recent Skype bug). You can provide a quick fix, that will buy time for sysadmins and downstream developers to test, fix and deploy the new version.
Now that you have a good security report, contact again the security researchers, journalists and users, provide them with the report, and emphasize what users risked, and how they can fix it. You can now comment publicly about the issue, make a blog post, send emails to your users to tell them how much you worked to protect them. And don't forget the consecrated formule: "we take security very seriously and have taken measures to prevent this issue from happening ever again".
Do you need help fixing your vulnerabilities? Feel free to contact me!
