It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem.

John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time…

Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys.

To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following:

Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no

You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section:

Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa

So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users.

When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA.

Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output.

Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected.

When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this?

The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face.

Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in.

Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

One of my goals and the goals of upstream developers was to create SELinux in such a way that it could be used by more then just the military/Department of Defense.   Traditional Mandatory Access Control Systems were built around the concept of Multi Level Security where the data and process would run at different security levels: Confidential, Secret and TopSecret.  Most non DOD environments don't classify their employees or data in this way.  They are much more like to define their security goals around what a user or a process is designed to do. 

• Apache is supposed to read these directories and connect to these ports. 
  
• USER-X Should not be allowed to execute files in his home directory. 
  
• The database should only be access through its unix domain socket.

All of these relationships can be described and written using type enforcement rules.  If I add a type/label to a process and a type/label to all files/objects on the system.  I then write rules on how the processes interact with the objects.  This is what SELinux does.  This is what type enforcement does.  

What is a process supposed to do? 
Allow the process to do this and nothing else.

In the case of a logged in user, you group all the processes together under a single type (guest_t).  And then you end up with all processes running as guest_t.  None of them can execute in the home directory, None can connect to the network, none can execute the setuid system call to become root. 

Often I give talks on SELinux and we get too deep into the internals of SELinux, I believe we need to bring it down to these simpler terms.

The beauty of this system is that it works for everyone from the highest levels of security in DOD environments down to the kiosk machine at your local library. 

Are non government entities starting to use SELinux?  You betch ya.

New York Stock Exchange

SELinux was a factor in the recently announced NYSE Euronext adoption of Linux:

NYSE Euronext also relies on Red Hat Enterprise Linux and its included Security-Enhanced Linux (SELinux) functionality to preserve the security of its platform. With trillions of dollars flowing through the exchange each month, security is a large and very important organizational focus. “We are very security conscious because we have to be. The operating system is a key part of every server that we operate and each server must be secure at all times. We maintain the security of our systems by relying on the SELinux features within Red Hat Enterprise Linux,” said Rubinow.

Their system handles US$141 billion per day in trades.

ESEC2008に行って来た。 Qtブースの人によると、 [http://trolltech.com/lang/japanese/qtopia-platform:title=Qtopia]という携帯プラットフォームは、 なんとLIDSを採用しているらしい。 AppArmorも検討（サポート？？）してるようなことを言ってた気がした。 SELinuxは華麗にスルーされたorz LIDSはファイルシステムを選ばないし、使い方もなんか手軽感があるのがいいのだろうか。

またも、組込み種ITの問い合わせがきた。素晴らしい。 どんなデバイスで遊んでいるんだろう。 リクエストに応じて久々に機能を追加してみた。 どんなドメインから実行されようとも、プログラムにドメインが付与されるもの。 domain foo_t; program_entry_force /bin/foo; とすると、/bin/fooが実行されると必ずfoo_tが割り当てられる。 svnに入れた。

かねてより提案していた SE-PostgreSQL のパッチに関して、Commit Fest:May の開始に伴い、開発チームリーダの１人である Tom Lane から物凄い勢いでレビューが返ってきた。
http://wiki.postgresql.org/wiki/CommitFest:May
http://archives.postgresql.org/message-id/3275.1210019965@sss.pgh.pa.us

それに合わせて、かなり大掛かりにコードをいじっている。
主なものでも
・PGACEのフックを static inline に変更
・initdb時に pg_security の代用ファイルを使わないように修正（On Memoryにキャッシュ）
・TRUNCATE→無条件DELETEへの書き換えをやめる（トリガ関数非互換）
・EXECUTEパラメータリストへのチェックを追加
・oidシステム列も書き込み可能にした
・WHERE句への条件追加をやめ、テーブルのスキャン中にフックを呼ぶようにした
・セキュリティポリシーを修正

それに加えて、パッチを投稿するためには、少なくとも regression test をパスしないといけないらしい。
最初に投稿した際のバージョンだと、大小様々に30個程度が FAIL になっていたようだ（死）が、上記のような改善を加えることで、現バージョンでは3個にまで減らすことができた。
このうち2個は機能追加に伴う真っ当なもので、あと1個は security_label 型の演算子の実装が必要であるためのもの。

[kaigai@masu sepgsql]$ make check
    ：
～（略）～
    ：
========================
 3 of 115 tests failed.
========================

security_label型に配列としての利用を許すオペレータが必要

*** ./expected/type_sanity.out  Mon Apr 21 13:14:24 2008
--- ./results/type_sanity.out   Thu May 15 22:35:00 2008
***************
*** 65,74 ****
       WHERE p2.typname = ('_' || p1.typname)::name AND
             p2.typelem = p1.oid and p1.typarray = p2.oid);
   oid | typname
! -----+---------
   210 | smgr
   705 | unknown
! (2 rows)

  -- Make sure typarray points to a varlena array type of our own base
  SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,
--- 65,75 ----
       WHERE p2.typname = ('_' || p1.typname)::name AND
             p2.typelem = p1.oid and p1.typarray = p2.oid);
   oid  |    typname
! ------+----------------
    210 | smgr
    705 | unknown
!  3403 | security_label
! (3 rows)

  -- Make sure typarray points to a varlena array type of our own base
  SELECT p1.oid, p1.typname as basetype, p2.typname as arraytype,

PostgreSQL本体のチェックより先に、SE-PostgreSQLがエラーを検出している

*** ./expected/create_function_1.out    Thu May 15 22:34:44 2008
--- ./results/create_function_1.out Thu May 15 22:35:01 2008
***************
*** 72,78 ****
  ERROR:  only one AS item needed for language "sql"
  CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
      AS 'nosuchfile';
! ERROR:  could not access file "nosuchfile": No such file or directory
  CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
      AS '(略)/regress.so', 'nosuchsymbol';
  ERROR:  could not find function "nosuchsymbol" in file "(略)regress.so"
--- 72,78 ----
  ERROR:  only one AS item needed for language "sql"
  CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
      AS 'nosuchfile';
! ERROR:  SELinux: could not obtain security context of nosuchfile
  CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
      AS '(略)/regress.so', 'nosuchsymbol';
  ERROR:  could not find function "nosuchsymbol" in file "(略)regress.so"

新しいシステムカタログpg_securityが追加されたので

*** ./expected/sanity_check.out Sun Nov 25 12:55:19 2007
--- ./results/sanity_check.out  Thu May 15 22:35:06 2008
***************
*** 111,116 ****
--- 111,117 ----
   pg_pltemplate           | t
   pg_proc                 | t
   pg_rewrite              | t
+  pg_security             | t
   pg_shdepend             | t
   pg_shdescription        | t
   pg_statistic            | t
***************
*** 149,155 ****
   timetz_tbl              | f
   tinterval_tbl           | f
   varchar_tbl             | f
! (138 rows)

  --
  -- another sanity check: every system catalog that has OIDs should have
--- 150,156 ----
   timetz_tbl              | f
   tinterval_tbl           | f
   varchar_tbl             | f
! (139 rows)

  --
  -- another sanity check: every system catalog that has OIDs should have

しかしこの regression test、作業ディレクトリの下に代替のルートディレクトリを作ってそこに PostgreSQL をインストールするという作りになっているので、正しいセキュリティコンテキストが付かずに難儀する。
仕方ないので、sepgsql_regression_test_mode という boolean を追加して、regression test に必要なパーミッションを与えるようにした。
user_home_tの共有ライブラリをロードできたりするので、通常運用では絶対に on にしてはならないが、まぁ、これはこれでアリだろう。

In case you hadn't noticed, Fedora 9 has been released. One of the many goodies to be included is SLIDE: the SELinux policy development IDE. This should be great news for application developers who want their projects to work well with SELinux.

It's been possible for some time now to quickly develop a loadable policy module when an application clashes with the shipped SELinux policy. The technique is quite simple: parse the audit log and generate rules which allow the previously denied accesses. This is a form of "learning mode", which risks encapsulating badness and being incomplete. It's often handy for resolving local issues, but not necessarily the kind of thing that a developer would want to use for creating shippable and maintainable policy.

This is where SLIDE comes in. It's an eclipse-based environment with deep knowledge of the SELinux policy infrastructure, facilitating policy development for everything from the simplest application through to the general system policy. It's not "SELinux policy for Dummies", but it does provide some useful high-level abstractions such as wizards. Developers who are interested in learning more about how to develop policy for their applications can now easily get started with SLIDE in Fedora 9. If not installed already, do so:

$ sudo yum install eclipse-slide selinux-policy-devel

SLIDE should then be available via Applications -> Programming -> Eclipse. Start a new project and follow the prompts to create a policy module for an application. The application doesn't even need to exist—this is simply a good way to learn about the policy framework. Note that the location of reference policy is /usr/share/selinux/devel/include.

Here are some screenshots (click for larger images):




Creating a new policy module via the wizard.




Guided interface. These fields are automatically populated, while elements may be expanded out for greater control.




Automatically generated initial policy ready for building or further development.


It would be immensely useful now to have a simple worked tutorial to help people get started in a practical manner. I'm not sure if anyone is planning to do this currently, so if you're looking for a way to dive in and contribute to the project, please get in touch via the mailing list. Otherwise, please wait until it falls from the sky.

Have fun!

Via a the Chennai ILUG mailing list, here's an interesting story: Linux rides pillion on Mumbai city buses. I like how this system uses GPS to figure the cost of each trip, rather than alternatives such as a single fare or complicated fare schemes.

Deployed in January 2007, the system is so stable that it will this month be officially extended to part of Mumbai's suburban railways as well. It is also secure, and has had no hacks and cracks, according to Kaizen.

Thanks to the system's use of Linux, BEST saved about inr 1.2 million on the point of sale infrastructure alone, as compared with a Microsoft Windows setup, Goriani says.

It's also slightly reassuring to see they're moved from telnet to SSH for remote management.

Sydney recently canned a smartcard-based bus ticketing system after spending AUD$95 million. Given that the same company was developing both systems (as well as the system for Singapore), and that such systems are fairly commonplace in modern cities, I think you could reasonably surmise that the problems in the Sydney system were not technical.

I’m sure many of you have heard by this point that there is a reported vulnerability in openSSL and openSSH.  The basis of this is that they keys that are generated when you use these tools (ie; installing openssh-server, etc) are generated in a weak manner and can be prone to simple brute force attacking.

If you’ve never installed openssh-server, used openssh-clients or generated an X.509 certificate you should be safe.  If you have done any of the above keep reading for a validation and fix instructions.  It can’t hurt to run the validation script in either case, just to be safe.

Security patches have been deployed to the Ubuntu archives so the first step is to, of course, apply any security patches available.

Am I Affected?

The first item at hand is verifying whether or not you have been affected by the vulnerability.  As mentioned above there are some common tasks that would qualify, but lets test your machine to make sure.

Download the script linked below and run it using the example syntax below:

dowkd.pl.gz (Download this file and unzip)

dowkd.pl PGP signature (Optionally verify the signature of the script)

Cut-n-Paste command-line example of downloading and running the test:

wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
gunzip dowkd.pl.gz
chmod u+x dowkd.pl
./dowkd.pl user
./dowkd.pl host <hostname>

If you see output similar to:

/home/username/.ssh/id_dsa.pub:1: weak key

…then you have been affected by the vulnerability.  If you do not see “weak key” reported then you are OK.

How Do I Fix My Machine?

To update your machine and patch the vulnerability the first thing you want to do is check for and apply any system updates available.  The main Ubuntu archives have been updated with the fixes.  If you are using an alternate mirror the fix may not have propagated yet, so you may not see it available for another few hours.

Apply any updates:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

You should see an update for openssl and openssh packages (along with anything else available).

After these new packages have been applied you’ll want to regenerate any keys that you’ve generated (ie; openssh keys, CA cert, etc).

UPDATE: The latest package release will automagically re-create any server-side ssh keys for you and notify you of the reason. Also, there is a new utility built into the latest release that will check keys for you. After your updates are applied try the tool:

ssh-vulnkey

To generate a new openssh key for your user: (This only required if ‘./dowkd.pl user‘ reports weak)

ssh-keygen -t dsa -b 1024

To generate a new openssh key for your server: (This only required if ./dowkd.pl host <hostname> reports weak)

sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
sudo dpkg-reconfigure -plow openssh-server

You should now run the validation script again and make sure it does not report any errors.  If you still see reported warnings such as:

/home/username/.ssh/authorized_hosts:1: weak key

…this means that you have authorized_host keys saved that are still affected.  Open the .ssh/authorized_hosts file with a text editor and delete the affected line (:1: means line 1, etc).

Continue to run the ./dowkd.pl script until no weaknesses are reported.

These steps should be run on any system that you manage to ensure they are sufficiently patched.

Random Posts

• Javascript clock
• Vista : Top 5!
• Folding v0.4 “Kickstart” Release
• HP + DSL + USB = new laptop
• Packaging Request For Folding
• Darwin Award?
• Setting up QEMU / KQEMU on Ubuntu 7.04 “Feisty”
• Switch to Linux Parody
• Refresh The Katapult Launcher in Kubuntu
• Death by DMCA

組込み向けのOSは、混沌としているようだ。 PCでは圧倒的なWindowsも、単なる1プレイヤーに過ぎない。 組込み向けOSのシェアを調べてみると、 Linuxは結構優勢らしいという情報が出てくる。 http://www.linuxdevices.com/news/NS2335393489.html VDCというところの調査だとLinuxは40%。 ただ、MSも必死にプロモーションしてるように思える。 Windowsの躍進もあるかもしれない。 国によっても違うと思われる。 国内の展示会だとTRO ...

Link

http://www.ibm.com/developerworks/linux/library/l-selinux/?ca=dgr-lnxw01SELinux