securityhttp://www.turnkeylinux.org/taxonomy/term/67/0
enCVE-2015-0235 GHOST: reboot or restart serviceshttp://www.turnkeylinux.org/blog/ghost-cve-2015-0235
<p>A remotely exploitable, 14 year old bug in glibc has reared its ugly head: <a class="reference external" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235">CVE-2015-0235</a></p>
<p>Security updates have been pushed out automatically, courtesy of Debian (<a class="reference external" href="https://security-tracker.debian.org/tracker/CVE-2015-0235">security tracker</a>) to TurnKey 13 installations. TurnKey 12 installations that have <a href="http://www.turnkeylinux.org/blog/extending-squeeze-security-support">enabled Squeeze LTS support</a> have also received an update.</p>
<p>If you want to verify that your system is patched you can compile and run <a class="reference external" href="https://gist.github.com/lirazsiri/e8223e7a1f5dc04c4c1f">ghosttest.c</a></p>
<div>
<h2>Running processes need to be restarted</h2>
<p>Here&#39;s the catch, even after applying the security updates any running process (e.g., service) that links to libc is still potentially vulnerable until restarted. The best thing to do if possible is reboot your system through Webmin or the console:</p>
<pre>
# /sbin/reboot</pre>
<p>The second best thing is to restart running services that link to libc.</p>
<p>I&#39;ve created a helper script to make this easier: <a class="reference external" href="https://gist.github.com/lirazsiri/1de361d010764027fbc0">lsof-restart-services</a></p>
<pre>
# lsof-restart-services
Syntax: /usr/local/sbin/lsof-restart-services lsof-pattern
Restarts running Debian services that match lsof-pattern (e.g., libc)&quot;
Environment variables:
DRYRUN=y If set, don&#39;t actually restart services, just echo
# DRYRUN=y lsof-restart-services libc
/etc/init.d/acpid restart
/etc/init.d/cron restart
/etc/init.d/ntp restart
/etc/init.d/rsyslog restart
/etc/init.d/shellinabox restart
# /usr/local/sbin/lsof-restart-services libc
/etc/init.d/acpid restart
[ ok ] Stopping ACPI services....
[....] Starting ACPI services...RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink
. ok
/etc/init.d/cron restart
[ ok ] Restarting periodic command scheduler: cron[....] Stopping periodic command scheduler: cron.
[ ok ] Starting periodic command scheduler: cron.
/etc/init.d/ntp restart
[ ok ] Stopping NTP server: ntpd.
[ ok ] Starting NTP server: ntpd.
/etc/init.d/rsyslog restart
[ ok ] Stopping enhanced syslogd: rsyslogd.
[ ok ] Starting enhanced syslogd: rsyslogd.
/etc/init.d/shellinabox restart
</pre>
<h2>&nbsp;</h2>
<h2>Mitigating factors</h2>
<p>This looks relatively difficult to exploit.</p>
<p>From the <a class="reference external" href="http://www.openwall.com/lists/oss-security/2015/01/27/9">Qualys Security Advisory</a></p>
<ul>
<li>The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.</li>
<li>Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the &quot;inet-aton&quot; requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe.</li>
<li>Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:</li>
<li>&quot;a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets.&quot; This makes it impossible to satisfy the &quot;1-KB&quot; requirement.</li>
<li>Actually, glibc&#39;s DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes (&#39;\&#39;) and makes it impossible to satisfy the &quot;digits-and-dots&quot; requirement.</li>
</ul>
<p>You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.</p>
</div>
http://www.turnkeylinux.org/blog/ghost-cve-2015-0235#commentssecuritySat, 31 Jan 2015 13:34:47 +0000Liraz Siri16939 at http://www.turnkeylinux.orgSecurity update regenerates stale SSH ECDSA host keyhttp://www.turnkeylinux.org/blog/ssh-ecdsa-security-update
<p><a href="https://github.com/plieven">Peter Lieven</a> from&nbsp;<a href="http://www.kamp.de/">KAMP.de</a> discovered a problem with TurnKey 13.0 where the OpenSSH ECDSA key is not regenerated on firstboot like the RSA and DSA host keys.</p>
<p>We&#39;ve issued a signed <a class="reference external" href="https://github.com/turnkeylinux/turnkey-hotpatches/blob/master/turnkey-core-13.0/debian/postinst">hotpatch</a> to TurnKey Core 13.0 that regenerates the ECDSA SSH host key. TurnKey deployments that have not disabled <a href="http://www.turnkeylinux.org/docs/automatic-security-updates">automatic security updates</a> (it&#39;s on by default) will have their ECDSA SSH host key regenerated automatically within the next 24 hours.</p>
<!--break-->
<p>If you don&#39;t want to wait for cron-apt to install the security update you can install the hotpatch immediately by executing this command as root:</p>
<pre>
install-security-updates
</pre>
<p>If you&#39;ve turned off security updates you can regenerate the ECDSA SSH host key by executing the following command in a root shell:</p>
<pre>
rm -f /etc/ssh/ssh_host_ecdsa_key*
dpkg-reconfigure openssh-server
</pre>
<p>Which is essentially what the hotpatch does.</p>
<div>
<h2>Warning: Remote host identification has changed</h2>
<p>If you&#39;re using an SSH client that supports ECDSA then after regenerating the ECDSA host key you may get the following error message when trying to login to your server:</p>
<pre>
~$ ssh my-turnkey-app.net
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
54:e9:46:79:f3:ff:5c:97:88:79:55:3c:80:af:39:a0.
Please contact your system administrator.
Add correct host key in /home/liraz/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/liraz/.ssh/known_hosts:1506
ECDSA host key for my-turnkey-app.net has changed and you have requested strict checking.
Host key verification failed.
</pre>
<p>Getting rid of this error is simple:</p>
<pre>
ssh-keygen -R my-turnkey-app.net
</pre>
<p>This removes all keys belonging to hostname from your $HOME/.ssh/known_hosts file.</p>
</div>
<div>
<h2>Why was this update necessary?</h2>
<p>The SSH host key is supposed to be secret. If a stale key is leftover from the build process then that makes active MITM attacks possible under certain conditions.</p>
<p>SSH host keys are the login shell equivalent of SSL certificates. They allow you to know that you are connecting to your server and not to some other server that is performing a man in the middle attack against your SSH session.</p>
<p>The ramification of this is limited by the fact that your SSH client needs to support ECDSA and be configured to default to that. Even if that is the case an attacker couldn&#39;t have used this to passively eavsedrop on your SSH connections. Rerouting network traffic in an active man in the middle attack would have been required to take advantage of this. Passively eavsedropping on the connection would not be enough to break the encryption because unique encryption keys are used for every session.</p>
</div>
<div>
<h2>Does my SSH client support ECDSA?</h2>
<p>Only users using SSH clients that supported ECDSA and are configured to default to that over RSA or DSA could have been effected by this.</p>
<p>OpenSSH gained ECDSA support since version 5.7. At the time of writing, Windows SSH clients such as Putty and WinSCP still don&#39;t have ECDSA support. Newer versions of Tera Term do support ECDSA however.</p>
</div>
<div>
<h2>Should I do anything else?</h2>
<p>If you used an SSH client that defaults to ECDSA and also use password based authentication with SSH you may want to consider changing your passwords, assuming you are worried about the type of attacker that has the capability to reroute network traffic and that would target your SSH sessions for an active man in the middle attack.</p>
</div>
<div>
<h2>How did this happen?</h2>
<p>Support for ECDSA keys was new to Debian Wheezy. The script that runs on firstboot only regenerated RSA and DSA keys. It was too specific. To prevent this from happening again I committed <a class="reference external" href="https://github.com/turnkeylinux/inithooks/commit/24a829f5a1dd31a910bf8fa2ec405e9b2e2d7b71">a fix to make SSH key regeneration more generic</a>.</p>
<p>I&#39;ve also added to our release checklist to go over the changelogs of the major packages that go into Core more carefully to try and spot any changes that could have security ramifications.</p>
<p>Many thanks again to Peter Lieven from <a href="http://www.kamp.de/">KAMP.de</a> for discovering this and reporting it.</p>
</div>
http://www.turnkeylinux.org/blog/ssh-ecdsa-security-update#commentsannouncementecdsasecuritysshWed, 13 Aug 2014 16:31:12 +0000Liraz Siri15984 at http://www.turnkeylinux.orgBackdoor in my Medialink routerhttp://www.turnkeylinux.org/blog/backdoor-in-my-medialink-wireless-router
<p>Just because you&#39;re paranoid doesn&#39;t mean they aren&#39;t out to getcha.</p>
<p>Here&#39;s another example of why we need free software running the Internet. When I bought my Medialink router it was the most popular brand of wireless router on Amazon.com. It is created by a Chinese corporation called Tenda.</p>
<p>And it comes with a root shell backdoor, which I just tested:</p>
<pre>
$ echo -ne &quot;w302r_mfg\x00x/bin/ps&quot; | nc -u -q 5 192.168.0.1 7329
PID USER VSZ STAT COMMAND
1 0 1360 S init
2 0 0 SWN [ksoftirqd/0]
3 0 0 SW&lt; [events/0]
4 0 0 SW&lt; [khelper]
5 0 0 SW&lt; [kthread]
6 0 0 SW&lt; [kblockd/0]
7 0 0 SW&lt; [kswapd0]
8 0 0 SW [mtdblockd]
16 0 2000 S httpd
18 0 1364 S /bin/sh
27 0 0 SW [RtmpCmdQTask]
28 0 0 SW [RtmpWscTask]
84 0 2328 S wscd -m 1 -a 192.168.0.1 -i ra0
85 0 2328 S wscd -m 1 -a 192.168.0.1 -i ra0
148 0 1200 S netdog
151 0 2000 S httpd
152 0 2000 S httpd
228 0 1360 S udhcpc -i eth2.2 -s /etc/udhcpc.script -p /var/run/ud
430 0 1316 S dnrd -a 192.168.0.1 -R /etc/dnrd -s 10.0.0.138
528 0 1076 S /bin/sntp 7
554 0 2352 S upnpd -f eth2.2 br0
555 0 2352 S upnpd -f eth2.2 br0
595 0 1368 S udhcpd /etc/udhcpd.conf
601 0 1160 S netctl FilterDaemon
614 0 1356 S sh -c bin/ps
615 0 1356 R bin/ps
</pre>
<p>The backdoor was discovered by <a class="reference external" href="http://www.devttys0.com/2013/10/from-china-with-love/">this hacker</a>.</p>
<p>Don&#39;t get me wrong, it&#39;s not like I trusted this thing before. On the other hand there are many ways running your network on a device with a remote root shell bound to a UDP port can turn out badly. So I applied the firmware update provided by Tenda (ha you caught us!). I&#39;m hoping in the new firmware they made the backdoor a little bit harder to find around (e.g., by adding a port knocking scheme).</p>
<p>I also went shopping for a new router without a built-in backdoor but it turns out they are all backdoored! The current most popular brand of router on Amazon.com is TP-LINK, another Chinese brand. They didn&#39;t even bother to <a class="reference external" href="http://sekurak.pl/tp-link-httptftp-backdoor/">patch their backdoor</a>.</p>
<p>FWIW, it&#39;s not just the Chinese routers, even the US made ones. At this point I guess the best we can hope for from the manufacturers is put in more of an effort to hide their shenanigans. A root shell bound to a UDP port? Come on.</p>
<p>In the end I did end up buying a new router, a TP-Link WDR4300. Yes the default firmware comes with a backdoor, but they&#39;re very popular and are supported by the <a class="reference external" href="http://wiki.openwrt.org/toh/tp-link/tl-wdr4300">OpenWRT - Open Wireless Router free software</a> project.</p>
<p>Once again, free software saves the day.</p>
http://www.turnkeylinux.org/blog/backdoor-in-my-medialink-wireless-router#commentsbackdooropenwrtsecurityThu, 24 Jul 2014 07:07:08 +0000Liraz Siri15891 at http://www.turnkeylinux.orgThe closest you can get to perfectly secure Bitcoin transactions (without doing them in your head)http://www.turnkeylinux.org/blog/secure-bitcoin-transactions
<p>@pa2013 helpfully posted Alon&#39;s <a href="http://www.turnkeylinux.org/blog/introducing-bitkey">BitKey announcement from last week</a> to the Bitcoin Reddit, which sparked an <a href="http://www.reddit.com/r/Bitcoin/comments/2batks/introducing_bitkey_a_secure_bitcoin_live_usbcd/">interesting discussion</a> regarding whether or not you can safely trust BitKey to perform air-gapped transactions. I started responding there but my comment got so long I decided to turn it into a blog post.</p>
<div>
<h2>Air-gaps are not enough</h2>
<p>As the astute commenters on Reddit correctly pointed out, just because you are using an offline air-gapped computer doesn&#39;t make you safe:</p>
<blockquote>For example an offline computer can have a tainted random number generator, modified to only feed you addresses that the attacker can sweep at a later point in time.</blockquote>
<p>I agree 100%. There are many ways a tainted air-gapped system can betray you, including smuggling out your secret keys via covert channel (e.g., USB keys, high frequency sound, covert activation of Bluetooth/wifi chipset, etc.)</p>
<p>The good news is that:</p>
<ol>
<li>Even if you assume BitKey is evil you can still use it to perform a highly secure Bitcoin transactions. Details in the <a href="#kill-bitkey">&quot;If I tell you I&#39;ll have to kill you&quot;</a> section below.</li>
<li>Most of the attacks against air-gapped systems are hard to hide if you build your own image from source.</li>
</ol>
<p>The bad news is that:</p>
<ol>
<li>
<p>Most people won&#39;t build from source.</p>
</li>
<li>
<p>Without deterministic builds you can&#39;t tell if the system image you are using is a faithful representation of source code.</p>
<p>A deterministic build means that everyone that builds from source always get exactly the same binary output, bit for bit.</p>
</li>
<li>
<p>You can&#39;t trust RNGs without deterministic builds. A properly designed &quot;evil&quot; RNG looks just like a &quot;good&quot; RNG. Just by observing the output it is possible to prove that an RNG is insecure but absolutely impossible to prove that it is secure.</p>
</li>
</ol>
</div>
<div>
<h2><a id="corrupt-rng" name="corrupt-rng"></a>Random Number Generators are the perfect hiding place for a backdoor</h2>
<p>The makes RNGs the perfect place to hide backdoors. I&#39;d bet money that RNG-level backdoors are where intelligence agencies like the NSA are focusing their efforts to compromise Internet security.</p>
<p>For this reason I personally don&#39;t trust RNGs at all when the stakes are high. Any RNG, not just the one in BitKey.</p>
<p>Why?</p>
<p>Even if you audit the source code that the RNG is being compiled from, you still have to trust that the compiler is translating source code faithfully, and worse this turns out to be a recursive problem that was recognized was recognized waaaay back:</p>
<p><a class="reference external" href="http://cm.bell-labs.com/who/ken/trust.html">http://cm.bell-labs.com/who/ken/trust.html</a></p>
</div>
<div>
<h2>A solution you don&#39;t have to trust is better than one you do</h2>
<p>In its current form BitKey is a swiss army knife of handy Bitcoin tools which you could use to implement any workflow. What&#39;s interesting is that this includes at least one workflow which don&#39;t require you to trust BitKey. I call it the &quot;<em>If I tell you I&#39;ll have to kill you</em>&quot; workflow.</p>
<p>But first, we need to recognize that there is an inescapable trade off between convenience and security and since the risk is proportional to the value of your wallet it doesn&#39;t make sense to enforce a specific trade off. We want to help make the most paranoid usage model practical for day to day use but at the same time, we want to create tools that let the user decide. For low value wallets maybe you&#39;re willing to trade off some security for better usability.</p>
<p>On the flip side, as someone who uses BitKey to perform very high security transactions routinely, once you get the hang of it&#39;s not too much trouble to go a bit overboard and sleep well at night. Better safe than sorry.</p>
</div>
<div>
<h2><a id="kill-bitkey" name="kill-bitkey"></a>If I tell you I&#39;ll have to kill you</h2>
<p>It turns out you can create secure Bitcoin transactions offline without having to trust the system performing the transaction. Do that and you can mostly dispense with having to trust third parties.</p>
<p>This is a good thing because trusted third parties are a security hole:</p>
<p><a class="reference external" href="http://nakamotoinstitute.org/trusted-third-parties/">http://nakamotoinstitute.org/trusted-third-parties/</a></p>
<p>Instead of trusting the solution you just have to trust the security protocol and its underlying assumptions, which you can verify yourself.</p>
<p>The trick is:</p>
<ol>
<li>Don&#39;t use the RNG. Provide your own entropy. Use a dice!</li>
<li>Assume BitKey is evil. Work around that by enforcing a strict flow of information to prevent it from betraying you.</li>
</ol>
<p>For example, let&#39;s say there are two computers: <span style="color:#0000FF"><strong>BLUE</strong></span> and <span style="color:#FF0000"><strong>RED</strong></span>.</p>
<p>I&#39;m calling this the &quot;<em>If I tell you I&#39;ll have to kill you</em>&quot; model because once you give BitKey access to the secret keys in your wallet you assume it will try anything to smuggle them out back to the attacker. To prevent that you will have to quarantine BitKey, get the signed transaction out, then kill it.</p>
<p>Now let me translate how that works in practice.</p>
<p><span style="color:#0000FF"><strong>BLUE</strong></span> is a regular Internet connected PC, running a watch wallet (e.g., BitKey in cold-online mode, or Ubuntu running Electrum in watch-only mode). Connected to <span style="color:#0000FF"><strong>BLUE</strong></span> PC is a <strong><span style="color:#0000FF">BLUE usb drive</span></strong>.</p>
<p><span style="color:#FF0000"><strong>RED</strong> PC</span> is an air-gapped PC that has no hard drive, NIC, Wifi, Bluetooth, sound card, etc. It only has a keyboard, monitor and USB port.</p>
<p>Next to <span style="color:#FF0000"><strong>RED</strong></span> is a <strong><span style="color:#FF0000">RED usb drive</span></strong>. It is NOT plugged into <span style="color:#FF0000"><strong>RED</strong></span>. (yet)</p>
<p>On <span style="color:#0000FF"><strong>BLUE</strong></span> you create an unsigned transaction and save it to a <span style="color:#0000FF"><strong>BLUE usb drive.</strong></span></p>
<p>On <span style="color:#FF0000"><strong>RED</strong></span> you boot BitKey into RAM (e.g., in cold-offline mode). You then plug in the <strong><span style="color:#0000FF">BLUE usb drive</span></strong> and copy over the unsigned transaction into RAM. Then you unplug the <span style="color:#0000FF"><strong>BLUE usb drive</strong></span>.</p>
<p>At this point <span style="color:#FF0000"><strong>RED</strong></span> has the unsigned transaction in RAM but it can&#39;t sign it yet because it doesn&#39;t have access to the wallet.</p>
<p>So you plug into <span style="color:#FF0000"><strong>RED</strong></span> the <span style="color:#FF0000"><strong>RED usb drive</strong></span> that contains the wallet. You sign the transaction. You encode the JSON of the signed transaction as a QRcode. You read the QRcode with your phone. Verify that the inputs and outputs are correct. You broadcast the signed transaction to the Blockchain from your phone.</p>
<p>Then you reboot the <strong><span style="color:#FF0000">RED</span></strong> airgapped computer and leave it turned off for a few minutes to take sure the wallet has been wiped from RAM.</p>
<p>The only thing coming out of <span style="color:#FF0000"><strong>RED</strong></span> is the QRcode for the signed transaction and you can verify that with a very simple app on a separate device like your phone.</p>
<p>It&#39;s not perfect security, because an evil BitKey might conspire with an evil phone by creating an evil QRcode that sends your Bitcoins to another address or leak your private key.</p>
<p>But it&#39;s as close as you can get without doing the transaction in your head, and BitKey has all the tools to let you do that.</p>
<h2>Areas for improvement</h2>
<ul>
<li><strong>Improve usability by adding a self-documenting wizard</strong>:<br />
<br />
Improve usability and reduce the potential for human error by adding a wizard mode in which BitKey guides you step by step in performing secure air-gapped Bitcoin transactions.<br />
&nbsp;</li>
<li><strong>Port BitKey to work on the Raspberry Pi</strong>:<br />
<br />
I recently bought a few Raspberry Pis for this purpose.&nbsp;A $35 air-gap running BitKey on super cheap open hardware woud not only be cheap and practical it would also prevent us from having to trust our PCs / laptops not to be compromised at the hardware level. On a typical laptop / PC there are way too many places for <a href="https://en.wikipedia.org/wiki/NSA_ANT_catalog">bad stuff</a> to hide, though I expect the truly paranoid will wrap their Raspberry Pi&#39;s in tinfoil just in case.<br />
<br />
Also, I think this would be a great opportunity to get TurnKey in general working on the Raspberry Pi.</li>
</ul>
</div>
<div>
<h2>How deterministic builds fit into the puzzle</h2>
<p>Deterministic builds are another way around the problem of having to trust third parties. As seen above, we can get very good security without them, but only by assuming the system we are using is already compromised and limiting how the poison can spread.</p>
<p>But for many applications that just isn&#39;t practical. Often you need a two way information flow (e.g., privacy applications) and there are too many ways for a malicious system to betray you.</p>
<p>Full system deterministic builds are going to be essential for those usage scenarios. It&#39;s not a silver bullet but unless everyone&#39;s build system is compromised, you can at least rely on the translation of source code to binary is faithful.</p>
<p>This improves security dramatically because:</p>
<ol>
<li>
<p>With deterministic builds you don&#39;t have to trust us not to insert backdoors into the binary version of BitKey.</p>
<p>I trust myself not to do that but coming from a military security background I can easily emphasize with anyone that doesn&#39;t.</p>
</li>
<li>
<p>You also don&#39;t have to trust us to be capable of resisting attacks by Advanced Persistent Threats (AKA super hackers) that might figure out how to worm their way into our development systems.</p>
<p>Personally, I believe it is unwise to expect any single individual or organization to resist truly determined attacks. If the NSA wants into your system they are going to get in.</p>
</li>
</ol>
<p>The problems with deterministic builds are:</p>
<ul>
<li>You still need to audit millions of lines of source code.</li>
<li>We don&#39;t have full-system deterministic builds yet. Nobody does. That&#39;s something a lot of people in the free software world are working on though.</li>
</ul>
</div>
http://www.turnkeylinux.org/blog/secure-bitcoin-transactions#commentsbitcoinbitkeysecurityTue, 22 Jul 2014 17:27:16 +0000Liraz Siri15884 at http://www.turnkeylinux.orgEnabling Debian 6.0 LTS Security Supporthttp://www.turnkeylinux.org/blog/extending-squeeze-security-support
<p>This announcement is for Debian 6.0 (AKA Squeeze / TurnKey 12) users who have not yet upgraded to Debian 7.0 (AKA Wheezy / TurnKey 13):</p>
<pre>
~# cat /etc/issue.net
Debian GNU/Linux 6.0
</pre>
<p>Support for security updates to Debian 6.0 officially ended on Saturday May 31 2014.</p>
<p>As you may have heard, for the first time Debian is experimenting with a five year Long Term Support (LTS) program that will extend support until Feb 2016:</p>
<p class="rteindent1"><a class="reference external" href="https://www.debian.org/security/2014/dsa-2938">https://www.debian.org/security/2014/dsa-2938</a></p>
<p>Good news for procrastinators. The catch is that if you&#39;re still using Debian 6.0 you have to manually enable your system to receive LTS updates.</p>
<p>If you don&#39;t do that then the next time there is a remotely exploitable security vulnerability your system could get compromised.</p>
<p>For example, the previous version of TurnKey (TurnKey 12.X ) based on Debian 6.0 no longer receives <a class="reference external" href="http://www.turnkeylinux.org/docs/automatic-security-updates">automatic security updates</a>. Those of you that still have systems running Debian 6.0 have three options:</p>
<ol>
<li>
<p>Manually enable LTS updates on your Debian 6.0 system:</p>
<pre>
~# apt-get install debian-keyring debian-archive-keyring
~# cat&gt;&gt;/etc/apt/sources.list.d/security.sources.list&lt;&lt;&#39;EOF&#39;
deb <a href="http://http.debian.net/debian/" title="http://http.debian.net/debian/">http://http.debian.net/debian/</a> squeeze-lts main contrib non-free
deb-src <a href="http://http.debian.net/debian/" title="http://http.debian.net/debian/">http://http.debian.net/debian/</a> squeeze-lts main contrib non-free
EOF
~# apt-get update
~# apt-get upgrade
</pre>
Check which packages on your system are not supported:
<pre>
~# apt-get install debian-security-support
~# check-support-status
</pre>
</li>
<li>
<p>Use TurnKey&#39;s backup and migration system (<a class="reference external" href="http:/www.turnkeylinux.org/tklbam">TKLBAM</a>) to migrate your data and configurations from a TurnKey 12 based system to an equivalent TurnKey 13 based system, which is based on Debian 7.0.</p>
<p>The advantages:</p>
<ul>
<li>
<p>If anything breaks you don&#39;t have to fix it in place and you still have the original system up and running. Less pressure.</p>
</li>
<li>
<p>Forces you to test your backups.</p>
</li>
</ul>
<p>TKLBAM is built into all TurnKey systems. If you&#39;re using plain old Debian you can install TKLBAM with this one liner:</p>
<pre>
wget -O - -q <a href="https://raw.github.com/turnkeylinux/tklbam/master/contrib/ez-apt-install.sh" title="https://raw.github.com/turnkeylinux/tklbam/master/contrib/ez-apt-install.sh">https://raw.github.com/turnkeylinux/tklbam/master/contrib/ez-apt-install.sh</a> \
| PACKAGE=tklbam /bin/bash
</pre>
</li>
<li>
<p>Upgrade Debian 6.0 in place to Debian 7.0:</p>
<p><a class="reference external" href="https://wiki.debian.org/DebianUpgrade">https://wiki.debian.org/DebianUpgrade</a></p>
<p>You can upgrade TurnKey 12 based systems to Debian 7.0 the same way you would upgrade any other Debian system. Remember that under the hood TurnKey is just a preconfigured, customized version of Debian with a few extra packages (e.g., like TKLBAM).</p>
</li>
</ol>
http://www.turnkeylinux.org/blog/extending-squeeze-security-support#commentslegacyltssecuritysqueezeMon, 02 Jun 2014 16:43:24 +0000Liraz Siri15692 at http://www.turnkeylinux.orgTurnKey 13 critical security issue (Heartbleed / CVE-2014-0160)http://www.turnkeylinux.org/blog/heartbleed
<p>Without action, your TurnKey 13 installations may remain vulnerable to the critical&nbsp;<a href="http://heartbleed.com/">Heartbleed</a>&nbsp;OpenSSL attack (<a href="https://www.debian.org/security/2014/dsa-2896">DSA-2896-1</a>&nbsp;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160">CVE-2014-0160</a>). This is not a theoretical attack. A remote exploit <a href="http://www.coresecurity.com/products/core-impact/recent-exploits-and-updates?title=heartbeat&amp;field_exploit_type_tid=All&amp;field_vulnerabilty_id_value=&amp;field_operating_system_tid=All">already exists in the wild</a>.</p>
<p><span style="font-size:12px; line-height:1.5em">TurnKey installations are configured to </span><a href="http://www.turnkeylinux.org/docs/automatic-security-updates" style="font-size: 12px; line-height: 1.5em;">install security updates automatically</a><span style="font-size:12px; line-height:1.5em">. Unfortunately, according to our testing installing the update is not enough.&nbsp;</span></p>
<p><span style="font-size:12px; line-height:1.5em">For the fix to take effect y</span><span style="font-size:12px; line-height:1.5em">ou&#39;ll need to either:</span></p>
<p><span style="font-size:12px">1) Reboot your system:</span></p>
<pre>
/sbin/reboot</pre>
<p><span style="font-size:12px">2) Individually restart any service </span>(e.g., webserver, shellinabox, webmin, etc.)&nbsp;<span style="font-size:12px">that uses the OpenSSL library:</span></p>
<pre>
<span style="font-size:12px">/etc/init.d/apache2 restart</span>
/etc/init.d/nginx restart
/etc/init.d/lighttpd restart
/etc/init.d/shellinabox restart
/etc/init.d/webmin restart</pre>
<h2>Your private SSL key may already have been stolen</h2>
<p>Fixing this vulnerability only protects you from future attacks. An attacker can use this attack to read arbitrary chunks of server memory containing private keys, sensitive login credentials or supposedly encrypted communications. The implications of this are profound.</p>
<p>If an attacker has already exploited heartbleed to to steal your SSL private key she can decrypt all past and future encrypted traffic even after the vulnerability has been fixed.</p>
<p>If this concerns you, you may want to seriously consider issuing new private keys and passwords for all effected services.</p>
<h2>Are your servers vulnerable?</h2>
<pre>
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 (vulnerable)
Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14 (not vulnerable)<span style="font-family:verdana,sans-serif">&nbsp; &nbsp;</span></pre>
<p>TurnKey 12.x solutions (based on Debian Squeeze) are NOT vulnerable to&nbsp;Heartbleed, as they shipped with a version OpenSSL that is not affected.</p>
<p>TurnKey 13.x solutions (based on Debian Wheezy) ship with a version of&nbsp;OpenSSL that IS vulnerable.</p>
<p><span style="font-size:12px">Additionally, the appropriate steps need to be taken for potentially&nbsp;leaked primary key material, secondary key material, protected content&nbsp;and collateral.</span></p>
<h2>What about new deployments?</h2>
<p>New deployments should not be affected as security updates are applied before the services are started.</p>
<h2>Testing for vulnerability</h2>
<p>You can use either the online or CLI utilities to test for&nbsp;Heartbleed:</p>
<ul>
<li><a href="http://filippo.io/Heartbleed/">http://filippo.io/Heartbleed/</a></li>
<li><a href="https://github.com/FiloSottile/Heartbleed">https://github.com/FiloSottile/Heartbleed</a></li>
</ul>
<h2><span style="font-size:1.7em; line-height:1.25em">Further reading</span></h2>
<ul>
<li><a href="http://heartbleed.com/">Heartbleed.com</a></li>
<li><a href="https://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability">Free Software Foundation statement on Heartbleed vulnerability</a></li>
<li><a href="http://www.techweekeurope.co.uk/news/heartbleed-bug-openssl-143353">&lsquo;Heartbleed&rsquo; OpenSSL Bug Left HTTPS Servers Vulnerable For Two Years</a></li>
<li><a href="http://www.coresecurity.com/products/core-impact/recent-exploits-and-updates?title=heartbeat&amp;field_exploit_type_tid=All&amp;field_vulnerabilty_id_value=&amp;field_operating_system_tid=All">Commercial exploit for Heartbleed</a></li>
</ul>
http://www.turnkeylinux.org/blog/heartbleed#commentsannouncementsecurityWed, 09 Apr 2014 11:45:45 +0000Alon Swartz15354 at http://www.turnkeylinux.orgImportant security notice: Your TurnKey system may no longer be receiving automatic security updateshttp://www.turnkeylinux.org/blog/broken-cron
<p>
I have some bad news and some good news. The bad news is that if your TurnKey installation is older than 2 weeks you may no longer be receiving security updates.</p>
<p>
The good news is that you are reading this and there is a very easy fix. Either reboot your system, or log in and restart the cron service:</p>
<pre class="literal-block">
/etc/init.d/cron start
</pre>
<p>
Until you start recron, security updates and other scheduler related services (e.g., daily backups) will not work.</p>
<div class="section" id="what-happened">
<h2>
What happened?</h2>
<p>
Ubuntu screwed up a <a href="https://bugs.launchpad.net/ubuntu/+source/pam/+bug/790532">recent security update</a>. There was a nasty bug. When installed, the update breaks cron, the scheduling daemon TurnKey uses to <a href="http://www.turnkeylinux.org/docs/automatic-security-updates">auto-install security updates</a>. Not good.</p>
<p>
According to a routine report generated from the access logs on our security repository, there are currently thousands of TurnKey installations affected by this issue. Those systems are not getting automatic security updates. There&#39;s no immediate risk, but that could quickly change if a remote vulnerability is discovered in the time it takes whomever is responsible for the server to figure this out.</p>
</div>
<div class="section" id="make-sure-we-can-always-reach-you">
<h2>
Make sure we can always reach you</h2>
<p>
There&#39;s moral in all of this: make sure we can always reach you somehow.</p>
<p>
Sure, usually we don&#39;t need to get your attention regarding security issues because TurnKey is configured to auto-install updates, but as this incident shows, we can&#39;t rely on that always working.</p>
<p>
This time we can&#39;t fix the issue on our side, since it effects the very auto-update mechanism that&#39;s usually used to fix security issues.</p>
<p>
The best we can do is try to reach out to users and inform them that there is an issue that they need to manually intervene to resolve. Hopefully we can get through to anyone subscribed to this blog or the <a href="http://www.turnkeylinux.org/announcements">News and Security announcements newsletter</a>, or that has a Hub account.</p>
<p>
In any case, we&#39;ll soon find out from the logs on the security repository just how many of our users we can or can&#39;t reach.</p>
</div>
http://www.turnkeylinux.org/blog/broken-cron#commentsnewssecurityubuntuThu, 16 Jun 2011 17:37:17 +0000Liraz Siri2359 at http://www.turnkeylinux.orgSecure, flexible and scalable Amazon EC2 instance preseedinghttp://www.turnkeylinux.org/blog/hub-preseeding
<p>
I&#39;d like to introduce Joe. He is a good looking, experienced sys-admin and like all good sysadmins, he has more stuff to do than time to do it.</p>
<p>
Joe wants to get up and running on Amazon EC2 with a Wordpress&nbsp;installation, and chooses to do so with a pre-configured appliance.&nbsp;These are the steps Joe performs:</p>
<ul>
<li>
Joe logs into his favourite Amazon EC2 console, specifies a&nbsp;Wordpress appliance, and other configurations.</li>
<li>
Clicks launch.</li>
<li>
Once the instance is running, he logs in using his SSH public key&nbsp;and changes the root password (it was set randomly on firstboot, right?).</li>
<li>
He then proceeds to change the MySQL root password as well (also&nbsp;set randomly on firstboot, hopefully!). Joe knows how to do this&nbsp;as he&#39;s an experienced sys-admin, do you?</li>
<li>
Finally, Joe logs into Wordpress using the default admin password&nbsp;(he noted the default password in the release notes before launching), resets the password and specifies his own email for the&nbsp;account.</li>
</ul>
<p>
While performing the above, Joe was holding his breath and working as&nbsp;fast as he could because he was previously hit by a <a href="http://en.wikipedia.org/wiki/Botnet">botnet</a> looking for&nbsp;random systems using default passwords and was compromised. Luckily this&nbsp;time he came out unscaved.</p>
<p>
Does this sound familiar? Well, it should because that&#39;s how it&#39;s&nbsp;<em>mostly</em> being done.</p>
<p>
You might be thinking to yourself <em>&quot;but I used the TurnKey Hub to set the&nbsp;root password for my instances, which also set the database password&quot;</em>.&nbsp;True, that has been a feature of the Hub from day one, but with the&nbsp;release of TurnKey 11.0 and the <a href="http://www.turnkeylinux.org/blog/end-to-default-passwords">end to default passwords</a>, we&#39;ve&nbsp;extended the Hub to support preseeding as well.</p>
<p>
The idea behind this was not only to make cloud deployments more secure,&nbsp;but to make it much easier. We wanted to simplify the process for Joe&nbsp;from the above to this:</p>
<ul>
<li>
Joe logs into the <a href="https://hub.turnkeylinux.org">Hub</a>, selects Wordpress and preseeds the&nbsp;configuration.</li>
<li>
Clicks launch.</li>
</ul>
<p class="rtecenter">
<img alt="" src="http://www.turnkeylinux.org/files/images/blog/preseed_hub.jpg" style="width: 480px; height: 528px;" /></p>
<div id="cke_pastebin">
The above is not a mock-up of a future implementation, it&#39;s live on the <a href="https://hub.turnkeylinux.org">Hub</a>.</div>
<div>
So how does it work? Read on...</div>
<div id="cke_pastebin">
&nbsp;</div>
<h2>
Brainstorming a solution</h2>
<div id="cke_pastebin">
The problem in preseeding an instance is sending the information&nbsp;(securely) to the instance.</div>
<div>
So how do you do it?</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
Idea #1: pass it through Amazon EC2 user-data?</h3>
<div id="cke_pastebin">
If you know a little about Amazon EC2 you&#39;ll know that when launching an&nbsp;instance you can specify <a href="http://www.turnkeylinux.org/blog/ec2-userdata">user-data</a>&nbsp;which is accessible from the&nbsp;instance via Amazon&#39;s API.</div>
<div>
&nbsp;</div>
<div>
But wait, do you really want to store authentication credentials in&nbsp;user-data?&nbsp;</div>
<div id="cke_pastebin">
&nbsp;</div>
<div id="cke_pastebin">
You could, but because any process on the instance that can open a&nbsp;network socket can access the user-data as it never expires, you&#39;ll&nbsp;probably want to firewall off the Amazon API as soon as it&#39;s not&nbsp;required anymore during instance initialization. But maybe the user of&nbsp;the instance needs access to the Amazon API? Crippling the service by&nbsp;design isn&#39;t a good solution in my honest opinion.</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
Idea #2: store it in the Hub&#39;s database, and let the server query the API</h3>
<div id="cke_pastebin">
So, instead of sending authentication credentials via user-data, why&nbsp;not send a unique identifier (e.g., SERVER_ID), so the instance can use&nbsp;the Hub&#39;s API to pull the credentials?</div>
<div id="cke_pastebin">
&nbsp;</div>
<div id="cke_pastebin">
Well, you could, but that would mean the Hub service needs to&nbsp;store the instance&#39;s configuration, passwords and all, in its database and delete it when it&#39;s no longer needed. Storing an item in a database for just one use is inelegant. But it&#39;s a natural solution if you only have a database, as I dicussed in a previous <a href="http://www.turnkeylinux.org/blog/django-celery-rabbitmq">blog post</a>, <em>&quot;when all you&nbsp;</em><em>have is a hammer, everything looks like a nail&quot;</em>.</div>
<div>
&nbsp;</div>
<div>
In my opinion, it ultimately comes down to <a href="http://en.wikipedia.org/wiki/Separation_of_concerns">separation of concerns</a>. For this type of pattern, the most natural solution would be some sort of&nbsp;messaging service. The Hub publishes a message to a&nbsp;queue, which the instance consumes.</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
Idea #3: pass it as messages using the Advanced Message Queuing Protocol (AMQP)</h3>
<div id="cke_pastebin">
So whats wrong with messaging? Nothing really, so long as you take care&nbsp;when designing the system for confidentiality and integrity - we don&#39;t&nbsp;want others eavesdropping on messages, or sending spoofed messages.</div>
<div id="cke_pastebin">
&nbsp;</div>
<div id="cke_pastebin">
Messages that fail a CRC or cannot be decrypted successfully should be&nbsp;discarded, and removed from the queue so not to block it.</div>
<div id="cke_pastebin">
&nbsp;</div>
<h2>
Designing infrastructure that is secure, scalable and extendible</h2>
<div id="cke_pastebin">
The solution we came up with is designed to be secure, scalable and extendible. Eventually it will support other cloud&nbsp;hosting providers, as well as provide bi-directional secure&nbsp;communication for future Hub-based services still under development.</div>
<div id="cke_pastebin">
&nbsp;</div>
<div id="cke_pastebin">
The solution uses each of the <em>brainstormed</em>&nbsp;solutions above for what they&nbsp;were designed for, and no more.</div>
<div id="cke_pastebin">
&nbsp;</div>
<div class="rtecenter" id="cke_pastebin">
<img alt="" src="http://www.turnkeylinux.org/files/images/blog/preseed_dfd.jpg" style="width: 640px; height: 412px;" /></div>
<div id="cke_pastebin">
<span class="Apple-style-span" style="color: rgb(90, 51, 32); font-family: 'Trebuchet MS',Trebuchet,'Nimbus Sans L',sans-serif; line-height: 16px; font-size: 13px; font-weight: bold; letter-spacing: 1px;">Data Flow Diagram (DFD) explained:</span></div>
<ol>
<li>
The user specifies preseeding data.</li>
<li>
The Hub tells Amazon EC2 to launch the instance with user-data which&nbsp;includes the SERVER_ID.</li>
<li>
The Hub creates a direct message exchange and queue for the server, which is configured to only receive messages sent from the Hub.</li>
<li>
The Hub publishes <a href="http://www.turnkeylinux.org/blog/python-symmetric-encryption">symmetrically encrypted</a> messages (incl. a CRC) to the&nbsp;server queue with preseeding data that only the server can&nbsp;decrypt.</li>
<li>
The instance pulls user-data from the Amazon EC2 API (SERVER_ID).</li>
<li>
The Instance registers itself with the Hub via an SSL secured API using the&nbsp;SERVER_ID, which responds back with the server subkey and messaging&nbsp;secret. Note that this can only be done once for security.
<ul>
<li>
<div id="cke_pastebin">
<strong>subkey</strong>: A one way hash generated from the user&#39;s APIKEY. It is&nbsp;unique for each server registered in the Hub, and is used as&nbsp;part of the exchange and queue naming structure.</div>
</li>
<li>
<div>
<strong>secret</strong>: A secure unique hash used for message encryption and&nbsp;decryption.</div>
</li>
</ul>
</li>
<li>
The instance consumes messages from the queue. Messages are decrypted&nbsp;and passed to the callback for processing (preseeding messages appends the <em>arg=value</em>&nbsp;to inithooks.conf).</li>
<li>
During inithooks execution, inithooks.conf is sourced so preseeding&nbsp;will happen. Once inithooks.conf is no longer needed, it is&nbsp;deleted.</li>
</ol>
<p>
In addition to authentication related preseeding, <a href="http://www.turnkeylinux.org/docs/tklbam">TKLBAM</a> is also&nbsp;preseeded with the HUB_APIKEY and is initialized, so performing the&nbsp;initial backup is as easy as executing <em>tklbam-backup</em> or using the TKLBAM webmin module.</p>
<p>
As always, the client side code that implements the above is open&nbsp;source, and can be found in the following projects: <a href="http://code.turnkeylinux.org/hubclient">hubclient</a>, <a href="http://code.turnkeylinux.org/tklamq">tklamq</a>, <a href="http://code.turnkeylinux.org/inithooks">inithooks</a>, as well as the above&nbsp;mentioned blog posts.</p>
<p>
<strong>Take the <a href="https://hub.turnkeylinux.org">Hub</a> for a spin and let us know what you think.</strong></p>
http://www.turnkeylinux.org/blog/hub-preseeding#commentsamazonawscloudec2hubsecurityMon, 03 Jan 2011 08:43:25 +0000Alon Swartz1829 at http://www.turnkeylinux.orgMaking TurnKey more turnkey - the end to default passwords http://www.turnkeylinux.org/blog/end-to-default-passwords
<style type="text/css">
table {
border-collapse: collapse;
}
td {
border: 1px solid #dcdcdc;
padding: 5px 12px;
}</style>
<p>
In our quest to make the upcoming TurnKey 11.0 release more &quot;turnkey&quot;, I&nbsp;set out to extend the firstboot inithooks to include application&nbsp;specific configuration hooks such as setting of the admin password, email&nbsp;and domain to serve (where applicable).</p>
<p>
I&#39;m glad to announce that the quest is now over, and that puts the end&nbsp;to default passwords.</p>
<center>
<img alt="" src="http://www.turnkeylinux.org/files/images/blog/wp-pass.jpg" style="width: 600px; height: 450px; " /></center>
<p>
But what about hosting/cloud deployment where the user doesn&#39;t have boot&nbsp;interaction? Well, all the configurations can be <a href="http://www.turnkeylinux.org/docs/inithooks">pre-seeded</a>.&nbsp;We&#39;ll be adding support for preseeding to the <a href="https://hub.turnkeylinux.org">Hub</a>&nbsp;soon after the 11.0&nbsp;release. Until then, the instances will use default passwords, but they&nbsp;can be easily changed by executing the inithooks directly.</p>
<p>
While on my quest, it was interesting to get a birds eye view of how the&nbsp;different applications store their passwords, so I thought I&#39;d share:</p>
<h2>
Comparison table (22 applications)</h2>
<table border="1" cellpadding="1" cellspacing="1" style="width: 200px; ">
<tbody>
<tr>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
<strong>clear</strong></td>
<td class="rtecenter">
<strong>crypt</strong></td>
<td class="rtecenter">
<strong>md4</strong></td>
<td class="rtecenter">
<strong>md5</strong></td>
<td class="rtecenter">
<strong>sha1</strong></td>
<td class="rtecenter">
<strong>salt</strong></td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/tomcat">tomcat</a></td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="www.turnkeylinux.org/trac">trac</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/otrs">otrs</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/twiki">twiki</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/torrentserver">mldonkey</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/joomla">joomla</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/mantis">mantis</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/wordpress">wordpress</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/dokuwiki">dokuwiki</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/phpbb">phpbb</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/fileserver">extplorer</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/gallery">gallery</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/deki">deki</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/mediawiki">mediawiki</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/moodle">moodle</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
prestashop</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
magento</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
vtiger</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/bugzilla">bugzilla</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/roundup">roundup</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/redmine">redmine</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
&nbsp;</td>
</tr>
<tr>
<td>
<a href="http://www.turnkeylinux.org/django">django</a></td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
&nbsp;</td>
<td class="rtecenter">
x</td>
<td class="rtecenter">
x</td>
</tr>
</tbody>
</table>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
Foot notes</h3>
<ul>
<li>
<strong>clear:</strong> Passwords are stored in clear text.</li>
<li>
<strong>crypt:&nbsp;</strong>Passwords are hashed with <a href="http://manpages.ubuntu.com/manpages/lucid/man3/crypt.3.html" rel="nofollow">crypt</a>&nbsp;or <a href="http://manpages.ubuntu.com/manpages/maverick/en/man1/htpasswd.1.html">htpasswd</a>.</li>
<li>
<strong>md4/md5/sha1:&nbsp;</strong>Passwords are put through a <a href="http://en.wikipedia.org/wiki/Cryptographic_hash_function" rel="nofollow">cryptographic hash function</a>, which is&nbsp;a deterministic one-way procedure that takes a block of data and&nbsp;returns a fixed-size bit string.</li>
<li>
<strong>salt:&nbsp;</strong>A <a href="http://en.wikipedia.org/wiki/Salt_(cryptography)" rel="nofollow">salt</a> (random bits) are added to the password before passing it&nbsp;through the hash function. Some of the applications use a randomly&nbsp;generated salt stored in a configuration file, others calculate it on the fly and&nbsp;add it the hash itself, while others use the user id as the salt.&nbsp;Using a salt is meant to add to the complexity and time it would take an attacker (who obtained the hashed passwords) to determine the original clear-text password.</li>
</ul>
<h2>
Now for some code snippets</h2>
<div id="cke_pastebin">
Just in case you&#39;re interested, here are some code snippets as well as&nbsp;the password storage locations. The full code will of course be included&nbsp;in the final 11.0 release.</div>
<div>
&nbsp;</div>
<h3>
tomcat</h3>
<pre>
doc = xml.dom.minidom.parse(TOMCAT_USERS).documentElement
users = doc.getElementsByTagName(&#39;user&#39;)
for user in users:
if not user.getAttribute(&#39;username&#39;) == &#39;admin&#39;:
continue
user.setAttribute(&#39;password&#39;, password)</pre>
<div id="cke_pastebin">
FILE: /etc/tomcat6/tomcat-users.xml</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
trac</h3>
<pre>
system(&quot;htpasswd -cb %s admin %s&quot; % (authfile, password))</pre>
<div id="cke_pastebin">
FILE: /etc/trac/htpasswd</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
otrs</h3>
<pre>
hashpass = crypt.crypt(password, &#39;ro&#39;) # 2 chars of username/email</pre>
<div id="cke_pastebin">
MYSQL: otrs2.users pw</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
twiki</h3>
<pre>
output = getoutput(&quot;htpasswd -bn foo %s&quot; % password)
hashpass = output.split(&quot;:&quot;)[1].strip()
</pre>
<div id="cke_pastebin">
FILE: /var/www/twiki/data/.htpasswd</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
mldonkey</h3>
<pre>
MD4_HASH=$(echo -n $PASSWORD | openssl dgst -md4 | tr [a-z] [A-Z])</pre>
<div id="cke_pastebin">
FILE: /var/lib/mldonkey/users.ini</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
joomla</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: jos_db.jos_users password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
mantis</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: mantis.mantis_user_table password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
wordpress</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: wordpress.wp_users user_pass</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
dokuwiki</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
FILE: /var/lib/dokuwiki/acl/users.auth.php</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
phpbb</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: phpbb3.phpbb_users user_password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
extplorer</h3>
<pre>
MD5_HASH=$(echo -n $PASSWORD | md5sum | cut -d &quot; &quot; -f 1)
</pre>
<pre>
hashpass = hashlib.md5(password).hexdigest()</pre>
<div id="cke_pastebin">
FILE: /var/www/extplorer/config/.htusers.php</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
gallery</h3>
<pre>
salt = &quot;&quot;.join(random.choice(string.letters) for line in range(4))
hashpass = salt + hashlib.md5(salt + password).hexdigest()
</pre>
<div id="cke_pastebin">
MYSQL: gallery2.g2_User g_hashedPassword</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
deki</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()
hashpass = hashlib.md5(&quot;1-&quot; + hashpass).hexdigest() # userid 1
</pre>
<div id="cke_pastebin">
MYSQL: wikidb.users user_password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
mediawiki</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()
hashpass = hashlib.md5(&quot;1-&quot; + hashpass).hexdigest() # userid 1</pre>
<div id="cke_pastebin">
MYSQL: wiki_db.user user_password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
moodle</h3>
<pre>
for line in file(conffile).readlines():
m = re.match(&quot;\$CFG-&gt;passwordsaltmain = &#39;(.*)&#39;;&quot;, line)
if m:
salt = m.group(1)
hashpass = hashlib.md5(password + salt).hexdigest()
</pre>
<div id="cke_pastebin">
MYSQL: moodle.user SET password</div>
<div id="cke_pastebin">
CONFFILE: /var/www/moodle/config.php</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
prestashop</h3>
<pre>
for line in file(conffile).readlines():
m = re.match(&quot;define\(&#39;_COOKIE_KEY_&#39;, &#39;(.*)&#39;&quot;, line)
if m:
cookie_key = m.group(1)
hashpass = hashlib.md5(cookie_key + password).hexdigest()
</pre>
<div id="cke_pastebin">
MYSQL: prestashop.employee passwd</div>
<div id="cke_pastebin">
CONFFILE: /var/www/prestashop/config/settings.inc.php</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
magento</h3>
<pre>
salt = &quot;&quot;.join(random.choice(string.letters) for line in range(2))
hashpass = hashlib.md5(salt + password).hexdigest() + &quot;:&quot; + salt</pre>
<div id="cke_pastebin">
MYSQL: magento.admin_user SET password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
vtiger</h3>
<pre>
hashpass = hashlib.md5(password).hexdigest()
$salt = substr($username, 0, 2);
$salt = &#39;$1$&#39; . str_pad($salt, 9, &#39;0&#39;);
$encrypted_password = crypt($password, $salt);
</pre>
<div id="cke_pastebin">
MYSQL: vtigercrm.vtiger_users user_hash, user_password&nbsp;&nbsp;</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
bugzilla</h3>
<pre>
$salt = &#39;&#39;;
for ( my $i=0 ; $i &lt; 8 ; ++$i ) {
$salt .= $saltchars[rand(64)];
}
$cryptedpassword = crypt($password, $salt);
</pre>
<div id="cke_pastebin">
MYSQL: bugzilla3.profiles cryptpassword</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
roundup</h3>
<pre>
hashpass = &quot;{SHA}&quot; + hashlib.sha1(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: roundup._user _password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
redmine</h3>
<pre>
hashpass = hashlib.sha1(password).hexdigest()</pre>
<div id="cke_pastebin">
MYSQL: railsapp_production.users hashed_password</div>
<div id="cke_pastebin">
&nbsp;</div>
<h3>
django</h3>
<pre>
salt = hashlib.sha1(str(random.random())).hexdigest()[:5]
hash = hashlib.sha1(salt + password).hexdigest()
hashpass = &#39;sha1$%s$%s&#39; % (salt, hash)
</pre>
<div id="cke_pastebin">
MYSQL: django_db.auth_user password</div>http://www.turnkeylinux.org/blog/end-to-default-passwords#commentsappliancespassphraseresearchsecurityMon, 20 Dec 2010 08:55:14 +0000Alon Swartz1771 at http://www.turnkeylinux.orgPassphrase dictionary attack countermeasures in tklbam's keying mechanismhttp://www.turnkeylinux.org/blog/tklbam-backup-passphrase
<h2>
Background: how a backup key works</h2>
<p>
In TKLBAM the <em>backup key</em> is a <em>secret</em> encrypted with a passphrase which is uploaded to the <a href="https://hub.turnkeylinux.org" rel="nofollow">Hub</a>.&nbsp; Decrypting the <em>backup key</em> yields the <em>secret</em> which is passed on to duplicity (and eventually to GnuPG) to be used as the symmetric key with which backup volumes are encrypted on backup and decrypted on restore.</p>
<p>
When you create a new backup, or change the passphrase on an existing backup, a new <em>backup key</em> is uploaded to the Hub where it is stored in the key field for that backup record.</p>
<p>
When you restore, tklbam downloads the <em>backup key</em> from the Hub and decrypts it locally on the computer performing the restore. Note that the Hub only allows you to download the <em>backup key</em> for backup records to which you have access (e.g., you are the owner).</p>
<h2>
Only you can decrypt your passphrase protected backups</h2>
<p>
All of this matters because it means that as long as you use a passphrase to protect the key, <strong>even the Hub can&#39;t decrypt your backups, only you can</strong> - provided you remember the passphrase (or failing that, at least have the escrow key stored in a safe place).</p>
<p>
In other words, the decryption of the <em>backup key</em> happens locally and at no point does the passphrase reach the Hub, so we can&#39;t decrypt your backup even if you asked us to. Neither can an attacker that has theoretically compromised the Hub, or a government agency that comes kicking down our door with a court warrant.</p>
<h2>
The problem with cryptographic passphrases</h2>
<p>
But wait. If an attacker has local access to the key, his ability to run dictionary attacks to find the key&#39;s passphrase is limited only by the computational resources he can throw at it.</p>
<p>
Remember there&#39;s a critical difference between a passphrase used for authentication purposes (e.g., to an online service) and a passphrase used for cryptographic purposes.</p>
<p>
By contrast, a passphrase used for authenticating to an online service doesn&#39;t need to be as strong as a passphrase that is used cryptographically because with an online service, even if no explicit countermeasures are used (e.g., IP blacklisting on too many failed attempts) there is still a network between the attacker and the service. The available bandwidth places a debilitating upper limit on how many passphrases can be tried per second. Also, in practice there are usually&nbsp; bottlenecks in other places which would slow down an online dictionary attack even further.</p>
<p>
But a passphrase used for cryptographic purposes assumes the attacker has access to the ciphertext, and that&#39;s a whole different ball game.</p>
<p>
To better understand what we&#39;re up against, here&#39;s the formula for calculating the size of the passphrase search space:</p>
<pre class="literal-block">
log(howmany_different_possible_values ** howmany_values) / log(2)
</pre>
<p>
For example, consider a typical 6 letter password.</p>
<p>
6 ASCII printable letters = maximum 42-bits of search space.</p>
<p>
That&#39;s a maximum of 4 trillion possible combinations. Which sounds like a lot. But it really isn&#39;t, since:</p>
<ol class="arabic">
<li>
<p class="first">
You can probably squeeze out about 1 million local passphrase tests per second from a modern multi-core workstation, assuming a typical passphrase encryption method is used.</p>
</li>
<li>
<p class="first">
This is one of those problems that are trivial to parallelize.</p>
<p>
If you rent just 100 computers (e.g., in the cloud) you could exhaustively search through 42-bits in about 5 days.</p>
<p>
And remember, today the bad guys often have millions of computers at their disposal via botnets.</p>
</li>
<li>
<p class="first">
People are very bad at choosing truly random passwords. A clever attacker will try the low hanging fruit first, so they&#39;re likely to find out your passphrase much sooner than by brute forcing blindly through the full search space.</p>
<p>
For example, say you know a 6 letter password is much too short for an encryption key and instead you&#39;re using a longer random combination of 10,000 common English words:</p>
<ul class="simple">
<li>
2 words = 18-bits worth of search space.</li>
<li>
3 words = 27-bits worth of search space.</li>
<li>
4 words = 36-bits worth of search space.</li>
</ul>
<p>
English words aren&#39;t very random so your &quot;paranoid&quot; 3 word, 17 letter passphrase may actually be easier to crack than a truly random combination of just 4 ASCII printable characters (28-bits).</p>
<p>
For comparison, let&#39;s see what happens if you use 6 random individual characters.</p>
<p>
If you just use random lowercase characters the search space is reduced to 27-bits which is 32,768 times easier to search through than the full 42-bit search space of 6-letter ASCII printable passwords.</p>
<p>
If you just use random lowercase characters and numbers, the search space is 30-bits which is 4,096 times easier to search through.</p>
<p>
If you just use random lowercase and uppercase characters and numbers, the search space is 35-bits which is 128 times easier to search through.</p>
</li>
</ol>
<p>
The good news is that each bit of search space doubles the expense for the attacker.</p>
<p>
The bad news is that it takes a truly random combination of 11 uppercase, lowercase characters and numbers just to reach 64-bits worth of search space, and a 10M strong botnet could crack even that in an average of 10 days.</p>
<p>
Bottom line: even your supposedly ultra-paranoid passphrase (e.g., r0m4n14nv4mp1r344rdv4rkn3st) of 4 random words from a dictionary of 150K words (in l33t speak) only has about 50-bits worth of entropy, despite being 27 characters long. A 10,000 botnet could crack that in about a day.</p>
<h2>
Countermeasures: increase computational cost</h2>
<p>
Though it&#39;s impossible to prevent these attacks entirely I&#39;ve implemented a couple of countermeasures in the way TKLBAM generates passphrase protected keys:</p>
<p>
1) <strong>The first trick</strong>: increase how computationally expensive it is to calculate the cipher key from the passphrase:</p>
<pre class="literal-block">
def _repeat(f, input, count):
for x in xrange(count):
input = f(input)
return input
def _cipher_key(passphrase, repeats):
cipher_key = _repeat(lambda k: hashlib.sha256(k).digest(),
passphrase, repeats)
</pre>
<p>
The principle is that calculating a hash costs CPU time so by feeding the hash into itself enough times we can linearly increase how expensive it is to map the passphrase-space to the key-space.</p>
<p>
For example, repeating the hash routine 100,000 times takes about a quarter second on one of the cores of my computer. If I use all 4 cores this limits me to generating 16 cipher keys per second. Down from 1.6 million cipher keys per second. So that&#39;s one way to dramatically reduce the practical feasibility of a dictionary or exhaustive brute force attack.</p>
<p>
Note that an attacker can&#39;t circumvent this calculation by searching through the key-space directly because even after we increase the cost of generating the passphrase space a 100,000 times over, the cost of trying to bruteforce the 256-bit key-space directly is still countless trillions of times greater.</p>
<p>
The weakness of this technique is that an attacker would have to pay the cost of mapping the passphrase-space (e.g., a dictionary) to the key-space only once when trying to crack multiple keys.</p>
<p>
2) <strong>The second trick</strong>: increase how computationally expensive it is to decrypt the key packet by increasing the number of times we pass it through encryption:</p>
<pre class="literal-block">
def _cipher(cipher_key):
return AES.new(cipher_key, AES.MODE_CBC)
ciphertext = _repeat(lambda v: _cipher(cipher_key).encrypt(v),
_pad(plaintext), cipher_repeats)
</pre>
<p>
This part of the computational expense is key-specific so trading off memory to pre-calculate the mapped key-space won&#39;t help you with this step.</p>
<h2>
Implementation notes</h2>
<h3>
Embedding repeat parameters in the key packet</h3>
<p>
The current implementation hardwires 100,000 repeats of the hash, and another 100,000 repeats of the cipher.</p>
<p>
This makes searching through the passphrase-space about 200,000 times more expensive. On my workstation it takes 0.5 seconds to encrypt or decrypt a key (per-core).</p>
<p>
I&#39;m not sure these are the ideal parameters but they are in the ball park of how much you can increase the computational expense before usability suffers.</p>
<p>
That&#39;s not to say you couldn&#39;t go higher, but there&#39;s a practical upper boundary to that too. If you&#39;re willing to wait about a minute for key generation/decryption you could increase the computational expense about 100 times over and that would give you 100 times better protection or allow you to use a password that is 100 times weaker with the same protection.</p>
<p>
Just in case, to allow the number of repeats to change or be user configurable in the future the key formatter routine embeds the repeat parameters into the unencrypted portion of the key packet. This allows the key parsing routine to extract these parameters from the key itself so it can just as easily parse a 0.5 second key (I.e., the current default) as a 5 second, or 50 second key.</p>
<h3>
Embedding a version id</h3>
<p>
Just to make sure the key format is future proof I&#39;m also embedding a version id into it.</p>
<p>
Embedding a version costs almost nothing (an extra byte) and makes it easier to support incompatible changes to the key format should the need arise (e.g., changing of cipher/hash, changing the format, etc.).</p>
<p>
Worst case scenario, we increment the version and implement a new incompatible key format. Old clients won&#39;t be able to understand the new key format but will at least fail reliably, and new clients will be able to support both new and old key formats.</p>http://www.turnkeylinux.org/blog/tklbam-backup-passphrase#commentsbackuppassphrasesecuritytklbamMon, 13 Sep 2010 09:14:11 +0000Liraz Siri1397 at http://www.turnkeylinux.orgMaintenance release: bugfixes, security updates, and better Amazon EC2 supporthttp://www.turnkeylinux.org/blog/maintenance-release
<p>
We&#39;ve just pushed out a maintenance release for the 2009.10 appliance batch featuring:</p>
<ul>
<li>
<a href="http://www.turnkeylinux.org/blog/maintenance-release#bugfixes">Bugfixes for all outstanding issues</a> (we&#39;re out of beta baby!)</li>
<li>
<a href="http://www.turnkeylinux.org/blog/maintenance-release#security">Security updates</a></li>
<li>
<a href="http://www.turnkeylinux.org/blog/maintenance-release#subscription">Simplified free subscription to Amazon EC2 AMIs</a></li>
<li>
<a href="http://www.turnkeylinux.org/blog/maintenance-release#amis">New and improved Amazon EC2 AMIs</a></li>
</ul>
<!--break-->
<p>
With the new Ubuntu 10.04 LTS release (Lucid Lynx) coming out in a couple of weeks this is the last TurnKey release batch based on the Ubuntu 8.04 series.</p>
<p>
Note that Ubuntu 8.04 is a Long Term Support release which will continue to be supported by Canonical with security updates for another 3 years (until April 2013).</p>
<p>
Unfortunately, unlike Canonical we don&#39;t have the resources to support multiple versions of Ubuntu simultaneously. So with this maintenance release we bid 8.04 a fond farewell. We&#39;re cleaning house and sweeping all the bugs and outstanding issues out of the way before we begin rebuilding the appliance library from the ground up on top of a brand new distribution.</p>
<p>
Fixing all the bugs from the previous release before rebuilding on a new distribution isn&#39;t just neat and tidy, it&#39;s good engineering!</p>
<h2>
<a name="bugfixes"></a>Bugfixed and out of beta</h2>
<p>
We&#39;ve fixed all the major issues reported by the community and are proud to remove the beta label from nearly all the appliances in the library.</p>
<p>
Many thanks to everyone who provided feedback and helped us track down bugs. Most of the issues were minor, but a couple (cough Zimbra cough) were nasty!</p>
<h2>
<a name="security"></a>Security updates</h2>
<ul>
<li>
<p>
<strong>Pre-installed all security updates</strong> that have come out since our last release batch. Existing installations have already been auto-updated, so you don&#39;t need to do anything.</p>
</li>
<li>
<p>
We now <strong>install security updates on first boot</strong></p>
<p>
Previously appliances were configured to install security updates daily but we&#39;ve realized that isn&#39;t good enough! We need to install security updates on first boot to prevent a window of vulnerability from opening between the time a fresh appliance is deployed and until the cron job that installs the security updates runs.</p>
<p>
On the other hand, installing security updates can take a few minutes and isn&#39;t critical in all usage scenarios (e.g., a local development VM) so when the appliance first boots the user is given a time-limited option to skip installation of the security updates.</p>
</li>
</ul>
<h2>
<a name="subscription"></a>Subscription to Amazon EC2 AMIs now easy and free</h2>
<ol>
<li>
<strong>Unified subscription (the easy part)</strong>: we&#39;ve created a single unified subscription that includes global access to all TurnKey appliance AMIs in all regions. Previously you had to subscribe to each appliance separately which was unnecessarily complicated.<br />
&nbsp;</li>
<li>
<strong>Free (as in beer)</strong>: we&#39;ve decided to let users try out TurnKey on EC2 for free while we solicit more feedback from the community on pricing <a href="http://www.turnkeylinux.org/polls/amazon-ec2-fees">here</a>.<br />
<br />
In the future a reasonable mark-up on usage fees could be a great way to support development and allow users to each share a small part of the burden in keeping the project sustainable. But the devil is in the details, so we want your feedback on that!</li>
</ol>
<h2>
<a name="amis"></a>New and improved Amazon EC2 AMIs</h2>
<p>
The latest batch of Amazon EC2 images now features:</p>
<ul>
<li>
<strong>Support for the us-west-1 region</strong>: meaning TurnKey images are now available in all EC2 regions under a new bucket naming scheme:
<ul>
<li>
turnkeylinux-us-east-1</li>
<li>
turnkeylinux-us-west-1</li>
<li>
turnkeylinux-eu-west-1</li>
</ul>
</li>
<li>
<strong>Support for automating EC2 instance setup</strong>: via a new user-data scripts mechanism (<a href="http://www.turnkeylinux.org/blog/ec2-userdata">blog post</a>).</li>
<li>
<strong>EBS auto-mounting support</strong>: replaces the old buggy ebsmount init script in previous images (<a href="http://www.turnkeylinux.org/blog/ebsmount">blog post</a>).</li>
</ul>
<h2>
<a name="hub-beta"></a>One more thing...</h2>
<p>
In the next few weeks we&#39;ll be launching a <strong>private beta</strong> of the TurnKey Hub, a web service we&#39;re building to make it super simple for users to deploy and manage TurnKey appliances in the cloud. If you&#39;re interested in receiving an invitation, <strong><a href="http://www.turnkeylinux.org/node/978">register here</a></strong>.</p>http://www.turnkeylinux.org/blog/maintenance-release#commentsappliancesawscloudec2newssecurityWed, 14 Apr 2010 06:15:15 +0000Liraz Siri1158 at http://www.turnkeylinux.orgSelf signed and trusted SSL certificateshttp://www.turnkeylinux.org/blog/ssl-certificates
<p>Keeping it simple, HTTPS is a combination of the HTTP and SSL/TLS protocols, which provides encryption while authenticating the server. The main idea is to create a secure channel over an insecure network, ensuring &quot;reasonable&quot; protection from eavesdroppers and man-in-the-middle attacks.</p>
<p>HTTPS assumes that special CA (Certificate Authority) certificates are pre-installed in web browsers. If your SSL certificate is not signed by one of these CA's, the browser will display a warning:</p>
<center>
<p><img alt="" src="http://www.turnkeylinux.org/files/images/ssl_error.jpg" /></p>
</center>
<p>TurnKey appliances generate self signed certificates on first boot to provide an encrypted traffic channel, but because the certificates are not signed by a trusted CA, the warning is displayed. In most cases, this is acceptable. If it's not, go get a signed certificate.</p>
<h2>Authoritatively signed certificates</h2>
<h3>Cost</h3>
<p>Authoritatively signed certificates can be costly, for example, Verisign (the most well known CA) charges $1,499 per year for their recommended certificate. There are cheap alternatives (I recently purchased a certificate from Go Daddy for $12.99) as well as a couple of free providers.</p>
<h3>Generate key and CSR</h3>
<p>First up is to create a certificate key and a certificate signing request (CSR). This can be done with OpenSSL.</p>
<pre>
apt-get update
apt-get install openssl
# replace bold type with your info
openssl req -new -newkey rsa:2048 -nodes -out <strong>www_example_com</strong>.csr -keyout <strong>www_example_com</strong>.key -subj &quot;/C=<strong>US</strong>/ST=<strong>Arizona</strong>/L=<strong>Scottsdale</strong>/O=<strong>Example Company Inc.</strong>/CN=<strong>www.example.com</strong>&quot;</pre>
<h3>Submit the CSR</h3>
<p>The above will generate two files, www_example_com.key and www_example.com.csr.</p>
<p>Once you have signed up for an authoritatively signed certificate, you will be requested to upload the CSR file or its contents.</p>
<h3>Verify the request</h3>
<p>The signing authority will need to verify the validity of the request and that it was submitted by the entity to which the domain in the request is registered, usually done by contacting the administrative contact for the domain.</p>
<p>Further steps may be required when requesting an <a href="http://en.wikipedia.org/wiki/Extended_validation">Extended Validation</a> (EV) certificate, which color the address bar green in recent browsers.</p>
<h3>Download signed certificate</h3>
<p>After validation, your signed certificate (crt) will be available for download. Most likely your signing authority will include an intermediate CA certificate bundle (trust chain).</p>
<p>Note: you should make a backup of all SSL related files.</p>
<h3>Generate PEM and placement</h3>
<p>Generate the pem from the key and crt</p>
<pre>
cat www_example_com.key <a href="http://www.example.com.crt" title="www.example.com.crt">www.example.com.crt</a> &gt; cert.pem
</pre>
<p>Place the generated pem and intermediate bundle (eg. bundle.crt) in /etc/ssl/certs/, and make them read-only to root.</p>
<pre>
chown root:root *.pem *.crt
chmod 400 *pem *.crt</pre>
<h3>Update configuration, enable SSL and reload webserver</h3>
<p><strong>Apache configuration</strong></p>
<pre>
&lt;VirtualHost *:443&gt;
SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateChainFile /etc/ssl/certs/bundle.crt
&lt;/VirtualHost&gt;</pre>
<pre>
a2enmod ssl</pre>
<pre>
/etc/init.d/apache2 force-reload
</pre>
<p><br />
<strong>Lighttpd configuration</strong></p>
<pre><strong>/etc/lighttpd/conf-available/10-ssl.conf </strong>
$SERVER[&quot;socket&quot;] == &quot;0.0.0.0:443&quot; {
&nbsp;&nbsp;&nbsp; ssl.engine&nbsp; = &quot;enable&quot;
&nbsp;&nbsp;&nbsp; ssl.pemfile = &quot;/etc/ssl/certs/cert.pem&quot;
&nbsp;&nbsp;&nbsp; ssl.ca-file = &quot;/etc/ssl/certs/bundle.crt&quot;
}</pre>
<pre>
lighty-enable-mod ssl
</pre>
<pre>
/etc/init.d/lighttpd force-reload
</pre>
<p><strong><br />
Do you use an authoritatively signed certificate? Is self-signed sufficient? <a href="#comment-form">Leave a comment</a>!</strong></p>http://www.turnkeylinux.org/blog/ssl-certificates#commentssecuritysslWed, 07 Apr 2010 10:25:32 +0000Alon Swartz1140 at http://www.turnkeylinux.orgWe don't need no stinking SSLhttp://www.turnkeylinux.org/blog/we-dont-need-no-stinking-ssl
<p><em>Why we disabled SSL and use an SSH tunnel for web site administration</em></p>
<p>Content managements systems like the one we're using for the web site (Drupal) need to provide a privileged administration interface which you usually want to access securely. Due to the insecure nature of the Internet, it's reasonable to assume your traffic may be intercepted at some point. So how do you prevent that?</p>
<p>Up until recently, we used SSL. You could access the web site from both:</p>
<ul class="simple">
<li><a href="http://www.turnkeylinux.org/" title="http://www.turnkeylinux.org/">http://www.turnkeylinux.org/</a></li>
<li><a href="https://www.turnkeylinux.org/" title="https://www.turnkeylinux.org/">https://www.turnkeylinux.org/</a></li>
</ul>
<p>Unfortunately, as the site grew in complexity this created a range of subtle but annoying paper-cut type problems.</p>
<!--break-->
<p>For example, I configured the site to use a content filter which translates local urls (e.g., /lamp) into absolute urls (e.g., <a href="http://www.turnkeylinux.org/lamp" title="http://www.turnkeylinux.org/lamp">http://www.turnkeylinux.org/lamp</a> ). This is necessary for links and images in blog posts to work correctly in RSS feeds and email updates (e.g., such as those provided by FeedBurner). We didn't want to do that by hand because we were using FCKeditor and IMCE which create local links by default and it wasn't any fun to have to translate every single link into an absolute URL by hand.</p>
<p>The problem is that Drupal cache saves pages AFTER the content filter, so guess what happens to links in pages you access via SSL? The situation could be a mix-up of http and https links which would be potentially confusing to both human visitors and search engines.</p>
<p>More importantly while in theory SSL should have protected our administration credentials in practice it didn't.</p>
<p>Drupal, along with many other web applications doesn't support secure SSL cookies. That means even if you login via SSL your cookie is still transmitted over the clear when you access the site, say accidentally, via HTTP. In a perfect world that might never happen but in practice it's quite a frequent mistake.</p>
<p>An attacker that can intercept your traffic can then intercept the cookie containing your session key and use that to access the site with your privileges.</p>
<p>So using SSL in this way doesn't really add that much security.</p>
<p>OTOH, session keys are temporary where passwords have much longer lifetimes so you still don't want to transmit your password in the clear.</p>
<h2>Alternative: access the site through an SSH tunnel</h2>
<p>So perhaps somewhat unintuitively, after considering our options we decided to turn off SSL and access the web site through an SSH tunnel which serves as a poor man's VPN.</p>
<p>That sounds a bit complicated but it really isn't.</p>
<p>From my ~/.ssh/config:</p>
<pre class="literal-block">
host tkl
DynamicForward 1081
</pre>
<p>Then when I ssh to tkl, which is the VPS which hosts the web site, this creates a virtual socks proxy bound to 127.0.0.1:1081. Constructing the tunnel in this way can be a bit of a hassle but you can set that up to happen automatically (future post).</p>
<p>We then configure SwitchProxy FireFox extension to make it easy to switch to browsing within the tunnel.</p>
<p>Configuration tips:</p>
<ul class="simple">
<li>disable the SwitchProxy toolbar (Views-&gt;Toolbars)</li>
<li>added my staging server test.turnkeylinux.org to &quot;No proxy for...&quot;</li>
</ul>
<p>And then to switch into the tunnel: Tools-&gt;SwitchProxy-&gt;tkl</p>
<p>A nice bonus is that in our case this setup seems to be noticeably snappier than using SSL.</p>http://www.turnkeylinux.org/blog/we-dont-need-no-stinking-ssl#commentsadminsecuritysshsslMon, 15 Feb 2010 06:34:57 +0000Liraz Siri1004 at http://www.turnkeylinux.org