Skip to main content

Hartwork Blog

Free Software, Music, Chinese Chess

Creating Fedora chroots on Debian, Gentoo, ... easily

Hi! Just a quick tip on how to easily create a Fedora chroot environment from (even a non- Fedora) Linux distribution. I am going to show the process on Debian stretch but it's not be much different elsewhere. Since I am going to leverage pip/PyPI, I need it available — that and a few non-Python widespread dependencies:

# apt install python-pip db-util lsb-release rpm yum
# pip install image-bootstrap pychroot

Now for the actual chroot creation, process and usage is very close to debootstrap of Debian:

# directory-bootstrap fedora --release 25 /var/lib/fedora_25_chroot

Done. Now let's prove we have actual Fedora 25 in there. For lsb_release we need package redhat-lsb here, but the chroot was is functional before that already.

# pychroot /var/lib/fedora_25_chroot dnf -y install redhat-lsb
# pychroot /var/lib/fedora_25_chroot lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:[..]:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 25 (Twenty Five)
Release:        25
Codename:       TwentyFive

Note the use of pychroot which does bind mounts of /dev and friends out of the box, mainly. directory-bootstrap is part of image-bootstrap and, besides Fedora, also supports creation of chroots for Arch Linux and Gentoo. See you :)

Fwd: Security (or lack of) at Number26

Hi! I would like to share a talk that I attended at 33c3. It's about a company with a banking license and accounts with actual money. Some people downplay these issues as "yeah, but the issues were fixed" and "every major bank probably has something like this". I would like to reply:

  • With a bit of time and interest, any moderate hobby security researcher could have found what he found, including me.
  • The issues uncovered are not mere issues of a product, they are issues in processes and culture.

When I checked earlier, Number26 did not have open positions for security professionals. They do now: Senior Security Engineer (f/m) https://n26.com/jobs/547526/?gh_jid=547526

The video: Shut Up and Take My Money! (33c3)

arc4random_uniform and avoiding modulo bias when using a random number generator

Using the arc4random_uniform function is recommend over using arc4random: Former is advertised as not having "modulo bias" issues, see man arc4random. (So I got curious, searched the web a bit, found this blog post, this answer and this link to the source code of one version used by Apple's. It took me a bit to figure things out but when I got it I was surprised how simple the solution is and the explanation could be. So here is my take at a better explanation.) Say we have a random number generator that produces numbers from 0 to 7 (i.e. 8 different values). Now in our application, we need 3 different values (i.e. 0 to 2, for simplicity). So the maximum source value SRC_MAX is 7, the maximum destination value DST_MAX is 2. If we calculate random values like

r = source_generator() % (DST_MAX + 1);

we end up with 0s and 1s a lot more than 2s — some people call that modulo bias , because there is bias for/against certain values. In the semi-visual world, the scenario looks like this ("XXX" marking troublemakers, i.e. values causing bias): 

 /---------\ /---------\ /---------\
|   |   |   |   |   |   |XXX|XXX|
 0   1   DST_                SRC_
         MAX                 MAX

Now to solve the modulo bias one could pick some way so that troublemakers are skipped, not taken into account. With troublemakers removed, we return to uniform distribution. To do that, when we hit a troublemaker we just roll the dice again until we no longer have a troublemaker. If our source generator is producing uniformly distributed output, that's guaranteed to terminate, quickly. In code, it could be a loop like this:

for (;;) {
  src = source_generator();  // [0 .. SRC_MAX]
  if (... no skip needed ...)
    break;
}
return src % (DST_MAX + 1);  // [0 .. DST_MAX]

How many (and which values) need to be skipped? The number of troublemakers calculates as

trouble_count = (SRC_MAX + 1) % (DST_MAX + 1);

e.g. 2 for our case because (7+1) % (2+1) = 8 % 3 = 2 because 2*3 + 2 = 8. Our input is a range ([0 .. SRC_MAX]) and our output is a (smaller) range ([0 .. DST_MAX]). There are two easy places where to skip values: (a) at the beginning or (b) at the end.

a) Beginning
                                    >   for (;;) {
         /---------\ /---------\    >     src = source_generator();
|XXX|XXX|   |   |   |   |   |   |   >     if (src >= trouble_count)
 0   1   DST_                SRC_   >       break;
         MAX                 MAX    >   }
                                    >   return src % (DST_MAX + 1);

b) End
                                    >   for (;;) {
 /---------\ /---------\            >     src = source_generator();
|   |   |   |   |   |   |XXX|XXX|   >     if (src <= SRC_MAX - trouble_count)
 0   1   DST_                SRC_   >       break;
         MAX                 MAX    >   }
                                    >   return src % (DST_MAX + 1);

To me (b) seems more intuitive, the arc4random_uniform sources I looked at went for (a). Now the only tricky part left is how to calculate

trouble_count = (SRC_MAX + 1) % (DST_MAX + 1);

for SRC_MAX = 0xffffffff = 2³²-1 without (SRC_MAX + 1) wrapping around to 0. I would go with

trouble_count = (SRC_MAX - (DST_MAX + 1) + 1) % (DST_MAX + 1);

The idea is that (k - n) % n equals k % n as we are dealing with modulus. That's all.

Loop variable collisions in Bash

Let's have a look at this simple Bash script:

#! /bin/bash
inner() {
    for i in {1..4}; do
        echo "  $i"
    done
}

outer() {
    for i in {1..3}; do
        echo "$i"
        inner
    done
}

outer

The output is ..

1
  1
  2
  3
  4
2
  1
  2
  3
  4
3
  1
  2
  3
  4

.. as expected. Now if we turn the for loops to C-style, we end up with this code:

#! /bin/bash
inner() {
    for ((i = 1; i <= 4; i++)); do
        echo "  $i"
    done
}

outer() {
    for ((i = 1; i <= 3; i++)); do
        echo "$i"
        inner
    done
}

outer

Before you continue, take a moment: What output do you expect? The same? The output we get is:

1
  1
  2
  3
  4

Why? By default, in Bash variables a global unless declared local, explicitly. That includes loop variables. The initial code had inner modify the global $i already; the collision did not show, because the master loop for i in {1..3}; do resets $i to the next value from list "1 2 3" rather than adding 1 to $i's current value. So right after inner returns, $i is "corrupted" for a brief moment in the original code, already. If we were to fix the C-style loop version, falling back to plain for loops is addressing symptoms more than causes. For addressing causes, I would like to propose both a soft and a hard fix:

#! /bin/bash
inner() {
    local i  # soft fix
    for ((i = 1; i <= 4; i++)); do
        echo "  $i"
    done
}

outer() {
    local i
    for ((i = 1; i <= 3; i++)); do
        echo "$i"
        ( inner )  # hard fix
    done
}

outer

The soft fix is declaring $i as local (to inner) so that it does not modify the global $i ("shadowing"). (The new local i in outer is for hygiene, and not taking part in this particular fix.) The hard fix is calling inner from a subshell so that outer does not have to trust inner on globals. To summarize:

  • Loop variables are global by default, too: Better turn them local.
  • Declare as many variables local as possible, in general.

Disable Komodo IDE debugger (bound to 0.0.0.0, run by default)

Komodo IDE starts a debugger bound to 0.0.0.0, by default. Maker ActiveState's reaction was rather irritating to me at the time when I asked for an option to bind to 127.0.0.1, instead (update: page offline by now). I can no longer add links to that post, but I can link to my demo Komodo IDE exploit script up here. Now it seems like the option to disable or even customize debugger settings was removed from the GUI: I cannot find it in version 9.3.2. I found a workaround when reading the source code that allows to still plug that hole in my setup. If I tweak the config file to an invalid port (outside of 0..65535 range), the debugger will just not start-up but Komodo starts up with no complaints. Nice :-)

# fgrep debuggerListenerPort ~/.komodoide/*/prefs.xml
/home/user/.komodoide/9.3/prefs.xml:
  <long id="debuggerListenerPort">77777</long>
/home/user/.komodoide/9.3/prefs.xml:
  <string id="debuggerListenerPortType">specific</string>

If you use that trick, be sure to check the version number in the path so you edit the latest / actually used version, 9.3 in my case.