( Pollux's blog )

Fusil (http://fusil.hachoir.org) has been accepted into Debian.

The description:

Fusil is a fuzzing framework designed to expose bugs in software by
changing random bits of its input.
.
It helps to start process with a prepared environment (limit memory,
environment variables, redirect stdout, etc.), start network client or
server, and create mangled files. Fusil has many probes to detect
program crash: watch process exit code, watch process stdout and syslog
for text patterns (eg. "segmentation fault"), watch session duration,
watch cpu usage (process and system load), etc.
.
Fusil is based on a modular architecture. It computes a session score
used to guess fuzzing parameters like number of injected errors to
input files.

Features

The next major releaser of FreeBSD, 7.0 will be released soon. There are many nice improvements:

• TCP socket buffers auto-sizing
• SCTP (Stream Control Transmission Protocol)
• Link aggregation / trunking
• New scheduler: ULE 2.0 / 3.0
• Most GIANT lock uses have been removed (increasing SMP/multi-thread efficiency)
• ZFS support
• Security event auditing
• New privilege separation capabilities
• SATA support
• pf firewall updated to 4.1
• Upgrade to gcc 4.2

Installation

The installation of 7.0rc2 in VirtualBox went smooth, except the network part. The installer itself has not changed, so I won't give details ...

For the network, there is a bug (not sure whether it's virtualbox or freebsd7, the bug was reported here) causing the network not to work. The solution is to force the media type:

ifconfig pcn0 media 10baseT/UTP

For automatic configuration of the if at startup, edit /etc/rc.conf:

ifconfig_pcn0="inet 192.168.1.66 netmask 255.255.255.0 media 10baseT/UTP"

(to be continued)

Default init

ANSI C requires all uninitialized static and global variables to be initialized with 0 (§6.7.8 of the C99 definition). This means you can rely on the following behavior:

int global;
void function() {
  printf("%d\n",global);
}

This will print 0, and it is guaranteed by the standard.

However, this is not handled by the compiler. All you will be able to see is that the variable is put in the bss section:

08049560 l     O .bss   00000004              static_var.1279
08049564 g     O .bss   00000004              global_var

It is the startup code of the linker which initializes the variables.

The C compiler usually puts variables that are supposed to be initialized with 0 in the .bss section instead of the .data section. Opposed to the .data section, the .bss section does not contain actual data, it just specifies the size of all elements it contains. The C compiler just *assumes* that the linker, loader, or the startup code of the C library initializes this block of memory with 0. This is an optimization; .data elements occupy space in the image (or ROM or flash memory) and in RAM whereas .bss elements need to occupy RAM space only if they are initialized at run-time.

(Gcc provides even an option (-fno-zero-initialized-in-bss) to do not rely on this optimization, that is, to put all 0-initialized elements into the .data section as well.

You can use

__attribute__((section, ".mysection))

on every uninitialized variable to instruct the compiler to put it into your own section.

I have a strange bug with bash shebang: when I try to give twistd as interpreter, bash tries to execute the script as a shell script !

Here is a simple, not working, twisted script with a shebang:

#! /usr/bin/twistd -y
from twisted.application import internet, service

Bash execution:

$ bash -c ./test.tac
from: can't read /var/mail/twisted.application

Bash is trying to execute the script as a shell script ! (from is a shell command).

Zsh execution:

$ zsh -c ./test.tac
Failed to load application: 'application'

The error is correct (there is no application defined in the twisted script). It really looks like a bug in bash ..

Starting from Lenny, apt support the https transport for apt repositories.

Before, this would give the error:

# apt-get update
E: The method driver /usr/lib/apt/methods/https could not be found.

On Lenny (and unstable), install the apt-transport-https package:

apt-get install apt-transport-https

And https repositories will now work.

This is no current backport for Etch on backports.org, because the hack for the transport is quite intrusive and require some deep modifications in the entire apt code. Maybe another site will propose it ?

Note: it seems there is currently no way to check the certificate or configure trusted certificates. This is a good step towards security anyway. Remember: always use trusted repositories (signed with a trusted key - see man apt-key for more information).

Inguma (http://inguma.sourceforge.net/), a free penetration testing and vulnerability research toolkit, has been accepted into Debian.

Coming soon: fusil

While searching for some security papers, I've been looking for something about LDAP injections.

Let's have a look on what OWASP says on their site:

The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

There is a problem here: there are some big differences between SQL and LDAP, which lead to differences in security:

• in SQL, commands and values are expressed in the same input (a string containing a command). Several commands can be specified in one string:

"SELECT field FROM table WHERE ...; DROP TABLE xx;"

• while in LDAP, the filter contains only filter parameters, in a specific representation (RFC 2254). This representation uses a prefixed form (boolean operator comes before the fields), and each field must be enclosed between parenthesis.:

"( & (uid=john.doe) (objectClass=person) )

OWASP gives some examples, for a filter (cn=%s):

1. If a user puts “*” on box search, the system may return all the usernames on the LDAP base
2. If a user puts “jonys) (| (password = * ) )”, it will generate the code bellow revealing jonys’ password

What ? One could make an application display the password ?!

The first line is true: any filter like (uid=*) will return all users having the uid attribute (this is called a presence filter). This won't allow to display specific fields, only select users. There is also a default limit (500) for such requests on OpenLDAP, by default.

So, indeed, one has to check the number of expected results. To avoid problems, you should really give the list of fields you are requesting, and not request complete entries, when possible.

To my knowledge, the second affirmation is just plain wrong ! The resulting filter will be

( cn = jonys ) ( | (password = * ) )

This filter is invalid : the form ( request1 )( request2 ) is invalid, in LDAP you must specify one filter, not two

ldapsearch -x -LL -h server -b 'dc=inl,dc=fr' '(uid=coin)(objectclass=person)'
ldapsearch: ldap_search_ext: Bad search filter (-7)

There are some conditions to make an injection: there must be a filter (before the user input) using a OR operator. For example, if using ( | (uid=%s) (condition2) ), the second part can be bypassed by using input name)(objectclass=*), since it will give:

( | (uid=name)(password=*))( (condition2) )

The second part of the filter is ignored, so the condition2 is ignored .. and the user name too.

However:

• This is only true for OR (if the condition before was a AND, it seems the is not way to bypass the first condition.
• a OR is very unlikely
• The consequences are still limited: you can't modify the data, only return a different set to the application.
• This won't bypass a password check (in LDAP, passwords are checked using a BIND operation)

Being curious, I have continued my search and found .. nothing interesting. The same example seem to be put on many sites without understanding it, and without explanations.

The most useful link I've found is http://elladodelmal.blogspot.com/2007/10/ldap-injection-blind-ldap-injection_9021.html (spanish), which is more descriptive. However, the conclusion (part3) is a big surprise:

• they test the injections on several servers and ..
• no one has executed the second filter : AD has just ignored it, and so did OpenLDAP !

(BTW, I'm just wondering what is the interested a security article which gives no result .. just a random thought).

So, to summarize:

• LDAP is subject to enumeration attacks
• LDAP is more robust than SQL to injections, due to the separation between LDAP commands, field list, and filter. The prefixed form of the filter is also of some help.
• Under certain circumstances (query preceded by a OR), injection seems possible, even if consequences are not that interesting: a weak application trusting only the result set is needed.
• You have to rely on the fact that the server will silently ignore the second part of the request. It would be easy for a LDAP server to return an error on this case, and thus reduce the risks.

Even though, that does not prevent you from using some precautions:

• escape characters (remember: never trust user input) ! especially ( ) \ *
• never put a OR in the filter preceding the input part
• use the BIND operation to validate passwords (never do something stupid like password=%s)
• when possible, validate the number of expected results vs actual results.

If anyone reading this has some more details, please leave a comment, I'd be happy to understand this correctly.

Quilt is a nice tool to manage series of patches, and is particularly adapted to subversion (not very useful for git, the concept of patch series is integrated). It can manage dependant patches, edition, updating patches for a code change, etc.

Start by telling quilt where to store patches:

$ export QUILT_PATCHES=debian/patches

Quilt will create the directory automatically when creating the first patch.

Now, suppose we want to create a new patch, called my_nice_patch:

$ quilt new my_nice_patch
Patch my_nice_patch is now on top

"On top" ? quilt manages patches as a stack, so you will have to push patches to apply them, and pop to deapply. Now that we have a patch name, we have to mark the files we will modify in this patch:

$ quilt add reports.py gather.py
File reports.py added to patch my_nice_patch
File gather.py added to patch my_nice_patch

So far so good. Three commands, and we have done nothing :) Files can be modified using your favorite editor (subliminal hint: vim), as usual. At any moment, you can get the diff between your modifications and the unpatched files:

quilt diff

will print a standard diff.

At this point, you have finished your patch. If you look at the debian/patches directory, you'll see .. nothing ! That's because a patch has to be "refreshed" to be written to disk.

$ quilt refresh
Refreshed patch my_nice_patch

The patch has been written to disk:

$ ls debian/patches/
my_nice_patch
series

The "series" files is an index of the patches, the other files are the patches. quilt uses the standard "diff" format, so patch can be used as usual (using diff -p1).

To apply all patches:

quilt push -a

To deapply all patches:

quilt pop -a

So what is nice with quilt ? It handles gracefully merges, updates, etc. Suppose your patch was done for version x of the sources, and you update the sources. You can reapply patches using the same commands:

$ quilt push my_nice_patch
Applying patch my_nice_patch
patching file gather.py
patching file reports.py
Hunk #1 succeeded at 145 with fuzz 1 (offset 38 lines).

Now at patch my_nice_patch

Ok, the patch applied with some fuzz, but correctly. How do I update my patch for the new sources ? Well, as usual:

$ quilt refresh 
Refreshed patch my_nice_patch

It wasn't hard ?

This is the end of this introduction to quilt, which can do much more advanced things than this simple example ! See the documentation for more.

Links:

• Introduction to quilt (pdf)
• Installation: apt-get install quilt

PostgreSQL 8.3 has been released today. Along with the usual amount of improvements there are some new features in 8.3 that should be of interest to PostgreSQL admins and developers such as:

• Integrated TSearch
• ENUM and UUID data types
• Faster sorting technique used for LIMIT operations
• Faster LIKE and ILIKE operations
• Lazy XID assignment which will make many read only operations much faster
• Asynchronous commits

Check out the full list of features at the PostgreSQL site or download it from the download section of their site. As usuel, you can also find many things in the very nice documentation, one of the best I've ever seen.

This is the first post on my blog ..

It will talk about my current job, working for INL, the company editing the authenticating firewall called NuFW; my hobbies (mainly related to security): Prelude, PostgreSQL, Netfilter, Linux, and other things...

In other words, maybe it will be interesting ...