Somewhere I read a post of yours saying CPFP depends on ucspi-tcp and netcat-traditional. Is this the case? While I’m confident in the security of the former definitely, I am definitely not of the latter’s. Look at the trackrecord: Netcat Netcat : CVE security vulnerabilities, versions and detailed reports
If this is indeed the way things are could you have it only depend on ucspi-tcp?
Thanks for digging that up!
Somewhere I read a post of yours saying CPFP depends on ucspi-tcp [u]and[/u] netcat-traditional. Is this the case?Yes. (https://github.com/Whonix/control-port-filter/blob/master/debian/control#L18)
While I'm confident in the security of the former definitely, I am definitely not of the latter's. Look at the trackrecord: http://www.cvedetails.com/product/4047/Netcat-Netcat.html?vendor_id=2310I am not sure it's the same netcat. Seems to be multiple rewrites by multiple people. For example http://www.cvedetails.com/cve/CVE-2008-6853/ links to http://www.netcat.ru/ and references version 3.12 while debian uses 1.10 (https://packages.debian.org/de/sid/netcat-traditional).
If this is indeed the way things are could you have it only depend on ucspi-tcp?I wouldn't know how to omit it.
Shouldn’t be a big risk either way, because it only sends commands to Tor’s ControlPort that passed the white listing test.
Nevertheless, I just made a quick test, we can either use netcat-traditional or switch to netcat-openbsd as a drop in replacement, looks like.
Test on Whonix-Gateway “9”:
nc -h→ got netcat-traditional
sudo apt-get install netcat-openbsdnc -h→ got netcat-openbsd
sudo service control-port-filter→ whonixcheck / Tor Browser New Identity on Whonix-Workstation still working.
Like to dig up a CVE comparison of netcat-traditional vs netcat-openbsd?
I’d take the OpenBSD implementation of netcat hands-down. Their devs are obsessed with code correctness of utilities of the base system code, which gives high confidence in its quality. It also supports IPv6 and unix sockets.
There are quite a few things wrong with their view of security otherwise , but that is besides the point. They are constantly auditing the base system code and utilities only, but they use stale packages that are not auditied at all, meaning that as soon as that httpd daemon starts your system is toast. They reject the concept of Mandatory Access Controls…
Is there a statement, that someone audited netcat-openbsd at least once from OpenBSD team? Do they publish a log on when they audited what?
vs
Whether older or newer means would mean better security is another question. Maybe we should rather check which one is maybe build with which hardening options.
I wouldn't know how to omit it.
That’s because ucspi-tcp doesn’t directly do that. However tcpcat a solution by the same author does and is the optimum candidate for replacing both options we discussed today.
tcpcat description from sourceforge:
tcpcat is a [b]simple[/b] program that is like `cat' but it works over tcp streams to allow you to cat from one host to another.
I like simple. Simple is excellent for security.
tcpcat manual on the author’s site.
Now the sequence of a control port call should be:
tcpserver >> CPFP >> netcat tcpcat >> Tor
/usr/bin/tcpcat is a shell wrapper using /usr/bin/tcpclient.
Got another argument. Comparing which hardening features are using.
checksec.sh --file /bin/nc.traditional
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH /bin/nc.traditional
vs
checksec.sh --file /bin/nc.openbsd
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH /bin/nc.openbsd
vs
checksec.sh --file /usr/bin/tcpclient
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
No RELRO No canary found NX enabled No PIE No RPATH No RUNPATH /usr/bin/tcpclient
netcat-openbsd shows best results here.
And argument from popularity.
There are better metrics to consider. Who the author is. How many lines of code (use SLOCCount) or descriptions.
Both must be taken into account together for a better decision.
ucspi-tcp is written by Daniel J. Bernstein. Gifted mathematician, cryptographer and computer scientist. Famous for his challenging of the US government ban on exporting strong cryptography, one of the most prominent cypherpunks of our time. He dedicated his time in writing replacements for insecure unix utilities, making code correctness priority. DJB’s software has impeccable track records in resilience and security. He also works on post-quantum cryptography. pqcrypto.org
Now without counting lines of code you can infer from the description how big the packages involved are
netcat-openbsd
At the same time it is a [b]feature-rich[/b] network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilitie
I don’t want feature-rich. This is a sensitive context we are using these tools in. Something with a small code size and coded correctly are my priority here, not bells and whistles. Contrast this with tcpcat’s description as simple.
Code correctness comes first. Adding an Apparmor profile is beneficial but should not be our first consideration ever when deciding about what to use.
In https://github.com/Whonix/control-port-filter/blob/master/usr/lib/cpf-tcpserver#L267 replacing
nc 127.0.0.1 9051 < "$OUT" > "$IN" &with
tcpcat 127.0.0.1 9051 < "$OUT" > "$IN" &as a drop in replacement doesn’t work.
So unless someone else or me is getting any inspiration on how to port from nc to tcpcat, the latter is unfortunately not an option.
In meanwhile I guess switching from netcat-traditional to netcat-openbsd should be the second best option?
I don't want feature-rich. This is a sensitive context we are using these tools in. Something with a small code size and coded correctly are my priority here, not bells and whistles.
From feature rich / more code doesn’t necessarily follow more vulnerable. Often if you do not use specific features, the code of that features won’t be in use.
Contrast this with tcpcat's description as simple./usr/bin/tcpcat is a shell wrapper using /usr/bin/tcpclient. Did you compare with tcpclient?
Code correctness comes first. Adding an Apparmor profile is beneficial but should not be our first consideration ever when deciding about what to use.Yes.
Some usage examples for tcpcat that may help before trying tcpclient: OpenBSD ports ∴ net/tcpcat
Here is an example using bash scripts to pass data to a daemon - in this case qmail, through using tcpserver and tcpclient or tcpcat togther. the djb way: qmail
The concept should be extendable to our situation I think.
Did you find anything encouraging in the front of tcpclient/tcpact tests?
No.
Are you still amenable to this suggestion but need more information or examples on using it?
AFAIK you need netcat to listen and print a command it receives. Someone posted printing a script with tcpcat that was received by tcpserver Serving http requests with tcpserver - Super User
There is no < "$OUT" > "$IN" &
just tcpcat 127.0.0.1 9051
The link uses tcpcat myserver 9000 to print the input
Are you still amenable to this suggestionYes.
examples on using it?Examples are appreciated. I need an example on how to use tcpclient bidirectional.
There is no [code]< "$OUT" > "$IN" &[/code]Well, we need to read from Tor's ControlPort as well as write to Tor's ControlPort. A "file" that is open for both, reading and writing. Since we need to authenticate, we cannot first write, then close. Because if you write and close, authentication is gone and you won't be able to read.
Abstract: If someone manages to send something to Tor’s ControlPort and read its answer using tcpclient / tcpcat, we may be able to re-use that for control-port-filter.
I did some research on this and maybe the syntax here might be of use:
Its a little tough for me to wrap my head around this but its helpful I assume. If this doesn’t work I’ll accept it. Its a last ditch effort to try and find something that can make this usable for us.
There is a complementary utility called tcprules that stores certain values received by tcpserver and used by tcpcat/tcpclient - in our case that could be the whitelisted commands. pwdgen is a custom service created by a bash script in the link above, ours is CPFP.
tcpclient example:
[code]#!/bin/sh
exec /usr/local/bin/tcpclient -RHl0 –
“${1:-0}” “${2:-129}” sh -c ‘exec cat <&6 |/usr/local/bin/delcr’[/code]
tcprules man:
http://cr.yp.to/ucspi-tcp/tcprules.html
I’ve asked on StackExchange but response so far is not encouraging.
Well, as said, this isn’t all that critical.
First of all, it assumes Whonix-Workstation being compromised. Second, the commands that are send to Tor’s ControlPort, that either nc (or as proposed tcpcat) will get to see are filtered already anyway. And if the filtering mechanism was broken, then Tor could be asked to revel the real external IP address anyway. In such a situation someone could try to exploit also nc and/or Tor for whatever that would be worth in that situation.
What would be more useful would be a rewrite perhaps in python and/or an AppArmor profile. On neither is work being done at the moment. Hopefully some day.
[quote=“HulaHoop, post:14, topic:424”]I’ve asked on StackExchange but response so far is not encouraging.
Thanks a lot for doing this!
What would be more useful would be a rewrite perhaps in python and/or an AppArmor profile. On neither is work being done at the moment. Hopefully some day.
In that thread I discovered a few months ago the Tails team planned to implement the filter in python and having it interact with Tor stem which they then backported to wheezy. This has been done as of sometime now. The merits of this is to simplify it and have less code to maintain, possibly making it yet more safer. I know you are not yet familiar with python but the code is already written by them. Might as well use it right? 
The feature ticket for stem backport has been completed:
https://labs.riseup.net/code/issues/6788
Here is the filter in python:
https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/local/sbin/tor-controlport-filter
Information on python deps used:
https://labs.riseup.net/code/issues/6742
Thanks a lot for doing this!
No problem. I’m keeping this on the backburner, decided to post the question on one of DJB’s mailinglists. Lets see what happens although not important.
I wonder if they are also chrooting the filter too. The git path seems to imply it.
Useful info, thanks.
whonixcheck is already using stem. Little python code that I wrote, which troubadour helped with and reviewed.
I also remember this thread:
Created a github ticket:
https://github.com/Whonix/Whonix/issues/290
I am not fully convinced that a python rewrite would improve security a lot. I am not saying the bash implementation is safer either.
The critical code here is handling the incoming connections as well as string parsing. Now, it’s clear that python by popular opinion is more hip than bash[+ coreutils] at the moment, but that doesn’t mean majority is right. Majority of mankind believed in past things that are now generally accepted as wrong as well. Basically both, bash and python allow coders to use a few simple lines of commands (connection handling / string parsing) to do stuff that would otherwise be much more complicated in C or asm code.
Have a million bash coders and/or a million python coders doesn’t automatically make either bash or python more secure. In both cases the complexity is reduced by the bash or python interpreter - which are both written in C. So this boils again down to which C code has been more throughly audited by C coders. The question to ask for example is, which string parsing code had the better track record in past.
Nevertheless, being right in spite of majority opinion isn’t worth much. You have to move with the times or the times move you. So at least for getting rid of the discussion and marketing reasons a python rewrite should be done.
Nevertheless, being right in spite of majority opinion isn't worth much. You have to move with the times or the times move you. So at least for getting rid of the discussion and marketing reasons a python rewrite should be done.
Very clear explanation. Really helped when researching what I did below. In terms of high level scripting languages, they all accomplish pretty similar tasks and have similar abilities. It comes down to which one you’re most comfortable with using. Who cares what others think?
So this boils again down to which C code has been more thoroughly audited by C coders. The question to ask for example is, which string parsing code had the better track record in past.
Yes.
Note: This is a long post but I tried compressing the information as much as possible please read it all carefully and the references too which contain useful information and support to the statements written.
Trackrecord:
Bash
Information on source package bash 4 CVEs
Python
https://security-tracker.debian.org/tracker/python no CVEs
Audit History:
Extensive research shows that both interpreters were not subject to any security auditing as of yet. CVE numbers alone are a weak indicator of either one’s security.
The two criteria for finding an alternative shell 1) It must have undergone security auditing 2) It must conform to the bash scripting language as close as possible so as to be useful for you.
Luckily I found something that satisfies these conditions, else I wouldn’t be writing this now 
Replacement:
-OpenBSD base system components undergo constant security auditing.
-Their fork is called oksh
-Its successor exists under the MirOS - an OpenBSD based security oriented project that has been around for a decade.
-Their fork is called mksh
-It further cleans up and fixes oksh and improves upon it. Code is shared between both projects.
-mksh exists in Debian repos
-mksh is largely compatible with GNU bash and can serve as a drop in replacement as its a member of the same lineage.
-mksh also supports more functionality than bash
-certain “bashisms” parts of a script that rely solely on bash-specific functionality could be scanned for in an automated way to identify for modification.
-According to mksh manual there is a restricted mode supported that could prove useful if no functionality disabled is needed by us.
-mksh had only one minor CVE sometime ago that was a result of the cleaning phase.
References:
http://www.openbsd.org/faq/faq8.html
These compilers have not gone through the security audit and do not contain security enhancements like those in the base system ... Unix shells: ksh and csh in the base system
http://www.openbsd.org/faq/faq15.html
The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system. Although we strive to keep the quality of the packages collection high, we just do not have enough human resources to ensure the same level of robustness and security.
ksh = base system = audited
And, beeing OpenBSD stock, ksh code is audited!
Some people ported OpenBSD's ksh to other systems. You may want to search for that on the Internet. I'm not sure if these versions of ported KSH is maintained or up to date. You can check out mksh, which is close to OpenBSD's ksh http://www.mirbsd.org/mksh.htm
Many variants of ksh. Both oksh and mksh are drastically improved forks of the original pdksh when it was released in the public domain.
https://www.mirbsd.org/mksh_old.htm
mksh is the heir of pdksh and contains all the latest fixes from upstream (so ca. 1995) and Debian. It is the only pdksh derivate currently being under active development. See above for other differences. The code really has been cleaned up and no longer contains any material under licences more restrictive than the BSD licence.
mksh is a direct descendant from the OpenBSD /bin/ksh and contains all of its bug fixes and enhancements except the “GNU bash-like $PS1” and “POSIX character class support in globbing” changes and the incompatible “ulimit can handle multiple limits in one invocation” difference. Some of the more weird diffs in oksh have not been merged either.
https://www.mirbsd.org/htman/i386/man1/false.htm
mksh manual
mksh available in Debian
https://security-tracker.debian.org/tracker/source-package/mksh
Minor CVE discovered when audited some time back
MirOS BSD (originally called MirBSD) is a free and open source operating system which started as a fork of OpenBSD 3.1 in August 2002.[2] It is intended to maintain the security of OpenBSD—from which it frequently synchronises code updates—with better support for European localisation.
Utility that checks for bash specific code.Very useful when porting from bash to similar shells.
Common Bourne compatible shells includethe original Bourne Shell (/bin/sh on most versions of UNIX), the GNU Bourne Again SHell (bash --- which is linked to /bin/sh on many distributions of Linux, making it their default shell), the Korn Shell (ksh), the Public Domain Korn SHell (pdksh --- which is /bin/ksh on some systems, /bin/sh on OpenBSD), the MirBSD Korn Shell (mksh -- which is /bin/sh on some systems)</blockquote>http://wiki.gentoo.org/wiki/Mksh
mksh is the MirBSD Korn Shell, an actively developed free implementation of the Korn Shell programming language and a successor to the Public Domain Korn Shell (pdksh). It is developed as part of the MirOS Project as native Bourne/POSIX/Korn shell for MirOS BSD, but also to be readily available under other UNIX-like operating systems. It targets users who desire a compact, fast, reliable, secure shell not cut off modern extensions, with unicode support.Recommendation:
Adapt any scripts that controls any component of the CPFP to use mksh, in adition to the filter itself.Longterm not as critical but will be referenced on CPFP page:
writing a MAC policy that restricts the scripts needed for CPFP functionality to only have access to interpreter. The policy should make the scripts immutable. The interpreter will only be allowed to run when triggered by the scripts in question.