An Overview of the Upcoming libModSecurity

Notice: This blog post was originally posted on SpiderLabs Blog.

libModSecurity is a major rewrite of ModSecurity. It preserves the rich syntax and feature set of ModSecurity while delivering improved performance, stability, and a new experience in easy integration on different.

libModSecurity - Motivations

While ModSecurity version 2.9.0 is available on different platforms (IIS, NGINX, etc…), It really favors an Apache Deployment. ModSecurity standalone is part of ModSecurity project and is basically a wrapper that packs requests from different formats into an Apache format, to later be processed by ModSecurity in the same fashion that it works on an Apache web server. That was certainly the fastest way to have ModSecurity running on different platforms but at the cost of performance and high amount of dependencies. Leading, for instance, to situations where NGINX users have to install Apache dependency in order to have the NGINX ModSecurity module working; see metabug ModSecurity/#661 for further information. The growth of the project in terms of integration with scripting languages or adoption in other platforms such as IDSs becomes very difficult because of those limitations.

The addition of new operators or general features is also limited because ModSecurity 2.9 (Sec Language) uses the Apache configuration parser to be loaded. In other words, the language format and conditional syntax could not be extended because it was dependent on a 3rd party software, that may not have our features in mind when they make changes. Even worse, sometimes bugs that heavily affect us are not on the priority list of the Apache (https://bz.apache.org/bugzilla/show_bug.cgi?id=55910).

LibModSecurity – Our goals

In order to circumvent those limitations, a year ago we decided to develop a new version of ModSecurity. A version for which the primary goal was not to introduce new features, but to add the possibility of an easy expansion and integration.

Due to the limitations of “ModSecurity standalone” and ModSecurity v2.9 architecture, we decided to move forward to implement something from scratch. By providing a new architecture while simultaneously supporting all the features of 2.9 we were able to remove many of the limitations that have burdened the project for the past few years.

In this blog post I plan to go over some of the details on why it was important to change the architecture and how some of those changes will lead to positive outcomes. Enjoy...

More about ModSecurity standalone architecture

As explained previously, the ModSecurity 2.x version has a high dependency on 3rd party projects including Apache. As it uses Apache internals directly, it was also using the libapr (Apache Portable Runtime). To highlight this point, we note that almost all memory allocation inside ModSecurity was allocated using libapr memory pools. This is, of course, not a problem, unless you want to remove APR.

To understand a little bit about the level of dependency of ModSecurity version 2.9 on 3rd party modules have a look on the Figure 1.

Figure 1. ModSecurity dependencies. (a) nginx extension. (b) IIS extension. Notice that both utilize the ModSecurity Standalone module.

At the right of Figure 1 we have several dependencies that are bound to the operators or request body parsers (e.g. libxml), some of those are mandatory on ModSecurity version 2.9.x and the idea is that those will become optional in ModSecurity version 3. The availability of a given feature will depend on the existence of the dependency. But, that is the subject for another blog post :)

On the left side of the Figure 1 are listed the dependencies that are mandatory for the ModSecurity v2.9.x core execution, without these core features of ModSecurity v2.9 cannot function. Removing the APR without removing other Apache dependencies was not be possible, as there are internal calls to the Apache API which demand data in the APR structure (APR memory pool). Additionally, removing just the Apache dependency also did not make sense, as it would need to be replaced by something Apache-like in any event, inheriting all those limitations. So the natural step was to move to a new architecture free of both Apache and APR. 

libModSecurity

The first thing that comes to mind when discussing “refactoring” of the ModSecurity core, is the possibility to have a segmentation of what is the “core” and what code is required to interact with a given web server, or as we call it a “connector”. Looking at the issues on GitHub it is difficult to tell which bug reports belong to each part of the code.

This monolithic design also puts pressure on us, its maintainers, when developing, testing, and packaging releases. This is because whenever we release in the current version, 2.x, everything needs to be released together (All platforms, even if there is no benefit to a given platform). Splitting the core from the “connectors” seems to be the right choice. Splitting the project give us numerous advantages, not only from the project planning perspective, but also the fact that the library can be easily ported, , and manipulated in this more modular architecture.

By splitting the project between “connectors” and “core”, the core naturally become a library, and the connectors become consumers of the core library. This way, ModSecurity core becomes completely independent of the underlying web server.

Another goal of the project was to reuse as much code as possible; this was done for two main reasons: (1) the code was tested and proven to work. (2) we didn’t need to implement everything from the scratch. So we first implemented a very minimalistic LALR parser (SecLanguage) to read the rules and transform them into C++ objects in memory. That limited language was slowly expanded as we added more operators, transformations and variables.

During the development of the core, other important utilities were also created. Two of those utilities deserve special attention, namely, the regression and unit test utilities. Both have a very important role in the development of ModSecurity version 3 and probably they will be even more important for the maturity of the project. In the future there will be a specific blog post to cover the regression and unit tests inside ModSecurity version 3.

One of the challenges on ModSecurity version 3 was to rewrite the SecRules, but to return exactly the same results of ModSecurity v2.9.x, thereby avoiding a compatibility break. This meant that we also had to reproduce the corner cases and unexpected behaviors of v2.9.x. This was achieved, so far, by the utilization of the regressions tests, were the requests are mimicked into JSON and the expected results are established from analysis of ModSecurity 2.9.

Going beyond the test, we needed to see ModSecurity version 3 working in practice as part of a web server. We choose the NGINX web server to be the first to fully implemented ModSecurity version 3. For that we started a different GitHub project, called ModSecurity-nginx (https://github.com/SpiderLabs/ModSecurity-nginx).

Figure 2 contains the dependencies of “ModSecurity NGINX connector”.

Figure 2. Dependencies of ModSecurity NGINX connector for libmodsecurity.

The ModSecurity NGINX connector, together with libModSecurity was presented at NGINX.conf 2015. At the conference we discussed various aspects of the ModSecurity connector and we obtained valuable feedback from the community to shape development of the connector.

Current status?

Currently we have the major features of libModSecurity implemented and ready to use. Although we don’t have support for collections yet, it is possible to load the OWASP core rule set version 3.0.0-dev.

So far, we are 374 commits ahead of master. Supporting almost all ModSecurity 2.x features. Figure 3. Contains a punch card with the commits to the project so far.

 Figure 3. Commits punch card.

Testability

While starting with versions 3, one of the main concerns was the project quality and that is why most of the features contain regression tests and/or unit tests. These tests can be executed on the developer’s machine but they are also executed on our BuildBots.

ModSecurity version 2.9.x already has its own regression and unit test utilities, however, they are very slow. A test with these utilities will take around 1 hour, has a dependency on Perl scripts, is Unix only, and is dependent on the web server.

With version 3 we fork the tests used in 2.9 into a separate GitHub project, and we added it inside ModSecurity by the utilizing a Git subtree. Having the test cases migrated into a separate project gives us the flexibility to run different tests with different versions of ModSecurity.

We also created another subset of tests that is specific  to the connector. This was done so we can segregate potential problems between the core and any connectors. In the specific case of NGINX, the regression tests were built as an extension of the NGINX server regression tests.

All these tests are executed for each commit that is performed on GitHub. This gives us the capability to promptly identify and fix any problem during the development of ModSecurity v3. It also gives us the ability to mimic problems without needing an entire web server configuration.

 Figure 4. Buildbot in the shape that we want to see, all green.

Performance

Performance is something that we are constantly measuring during the development of version 3. Instead of using the DebugLogs, with performance time stamps, we created SystemTap scripts that allow for real time instrumentations. SystemTap also allows the creation of flame charts. As demonstrated on Figure 5.

Figure 5. ModSecurity version 3 execution time using OWASP CRS version 3.0.0-dev.

The Figure 5 illustrates the mean times of each rule, grouped into different phases. Notice that the entire execution of the OWASP CRS took 483 microseconds. That specific subject deserves a creation of a specific blog post, together with the possibility of rules optimization.

What is next?

As mentioned, the libModSecurity still isn’t feature complete when compared to ModSecurity version 2.9.x. Your help is more than welcome to support that initiative. Currently, we have missing Connectors, Operators, Transformations, and Variables. How do you want to help?

Connectors

As mentioned before, currently we only have connector for nginx. In other words, Apache users will not have any benefit from ModSecurity v3, at least, not yet.

The development of the connectors for IIS and Apache will start as soon as we have a version of ModSecurity v3 released, unless someone from the community starts to develop it :)

Operators, Transformations and Variables

A question that we frequently receive is how to start coding for ModSecurity. Well, this is a good opportunity. The missing features in ModSecurity versions 3 are not very difficult to, plus, many of them already contain a description of what needs to be done. Some even have the file already, and just need to be filled. For a complete list of missing features with descriptions, check here:

• Missing transformations
• Missing variables
• Missing operators
• Missing features
• Missing documentation

Although all the operators needed by the ModSecurity SLR commercial rules are already supported inside ModSecurity version 3, we just encourage the usage of ModSecurity version 3 to advanced users. ModSecurity version 3 was not released yet, thus, not considered stable. Once it is released it will be 100% compatible with our SLR commercial rules.

Testing!

At this stage of the development testing is very important. We count on the community to provide feedback and report any issue on ModSecurity version 3. We are aiming to have a release candidate soon, ideally with only a small number of issues.

ModSecurity Python Bindings: Parsing ModSecurity rules from Python

Notice: This blog post was originally posted on SpiderLabs Blog.


One of the good things about the next generation of ModSecurity, libModSecurity (AKA ModSecurity version 3), is the fact that it portable to almost any platform. This extensibility makes the use of bindings for other languages, beyond C/C++, very useful. For those that are unfamiliar with the concept of a ‘binding’, the term describes an interface between two different languages. In the case of ModSecurity this binding will provide an interface that allows you to use libModSecurity functionally inside your scripting language of choice, with negligible loss of performance.

The libModSecurity Python bindings may serve many purposes; for instance, it could be leveraged to rapidly (and easily) create a custom web interface for ModSecurity. However, we are not limited to simply displaying information, the new bindings give you nearly all the capabilities that you would have interacting with libModSecurity from native C, allowing you to, for example, display ModSecurity rules in any fashion that you desire, with almost zero effort. A simple usage is demonstrated on the Figure 1.

Figure 1. ModSecurity being used inside a Python shell.

Bindings for languages others than Python will be also created. In fact, the utility that was used in the creation of the Python bindings, SWIG, can also generates interfaces to other languages such as: Ruby. You are welcome to volunteer to expand your favorite language to add ModSecurity capabilities.

In this blog post I will dive into the creation of a simple console utility to load and list a set of rules in a elegant way. For this I will start with the compilation of the ModSecurity-Python-bindings.

Notice: The ModSecurity Python bindings depend on the libModSecurity which is publicly available on ModSecurity GitHub, but it is not considered stable release at this point yet.

Installing ModSecurity Python Bindings

Before starting the installation of the ModSecurity Python bindings, make sure you have libModSecurity installed and operational on your machine. For further information about libModSecurity and how to install it, please see the README at ModSecurity’s GitHub repository, here: https://github.com/SpiderLabs/ModSecurity/tree/libmodsecurity . Of course, you will also want to make sure you have Python installed and all the developer utilities you may need on your Linux .

Once libModSecurity is installed, it is time to proceed with the installation of the ModSecurity Python bindings. Simply download the code from our GitHub repository, and proceed with the compilation, as demonstrated below:

  $ git clone http://www.github.com/SpiderLabls/ModSecurity-Python-bindings
  $ cd ModSecurity-Python-bindings
  $ make
  $ sudo make install

Once this process is finished, it is a good idea to test your new installation. You can do this by running the test script provided. This can be accomplished using the following command:

  $ ./test/t.py

If everything is alright, you should not get any error messages from Python.

The hello world script

With the ModSecurity Python bindings installed and tested it is time to create your first ‘hello world’ application using the ModSecurity library. Let’s start with something very simply like checking the ModSecurity version that we are playing with.

Inside libModSecurity we expose the whoAmI() method which describes which version of ModSecurity you are bound with. Further information about this method, can be found here: https://github.com/SpiderLabs/ModSecurity/blob/libmodsecurity/src/modsecurity.cc#L67-L78

Let’s use the whoAmI() method, to print the libModSecurity version. We demonstrate proper usage in Script 1 below.

#!/usr/bin/python

from modsecurity import *

modsec = ModSecurity()
s = “Hello World, I am: “ + str(modsec.whoAmI())
print s

Script 1. Hello world using libModSecurity.

As output, you should be able to see something similar to the Figure 2.

Figure 2. The output of the hello world script.

Loading the rules

The next step is to add a few more pieces to our script allowing it to actually load a given set of rules. Make sure you have a workable set of ModSecurity rules before you start to code. A good set for this example might be the OWASP CRS 3.0 ruleset, available here: https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-dev

Notice: Make sure you download the version 3.0.0-dev. Our parser is not 100% compatible with ModSecurity v2.9.x yet. It may not work with other versions of CRS.

Using our first example, start by commenting out the “Hello World...” string and the associated print statement. These two pieces won’t be necessary for this step. Your script should look similar to example provided in Script 2.

#!/usr/bin/python

from modsecurity import *

modsec = ModSecurity()
#s = “Hello World, I am: “ + str(modsec.whoAmI())
#print s

Script 2. Hello World script with the unnecessary strings commented.

The rules in ModSecurity are loaded through a Rules object. While the Rules object may be merged with other objects of the same type, in this script let’s keep it simple. For this example we just need to load a set of rules from a file and print them to the console. Again, a very simple utilization for libModSecurity.

We can load the rules, using the loadFromUri() method, which takes one argument as follows: “loadFromUri('/path/to/the/rules/file.txt')”. The loadFromUri() method allow us to load a set of rules into memory. Notice that this method will return “-1” if there are any problems while loading the rules. If this occurs you can call the getParserError() method to get more information about any possible errors. The loadFromUri() method must be called with the path to a rules file as a target, as demonstrated in Script 3.

#!/usr/bin/python

from modsecurity import *

modsec = ModSecurity()
#s = “Hello World, I am: “ + str(modsec.whoAmI())
#print s
rules = Rules.loadFromFile(“/path/to/your/v3.0.0-dev/rules/REQUEST-10-IP-REPUTATION.conf”)

Script 3. Loading the rules from a given file.

The Rules object has provides the getRulesForPhase() method which is called as follows: “rules.getRulesForPhase(phase_number)”. Calling this method will return a vector of Rule objects. The Rule object contains all the properties associated with a given rule. To list all the rules from the target file that will load during a given phase you may simply iterate over the returned value from getRulesForPhase(). This is demonstrated in Script 4.

#!/usr/bin/python

from modsecurity import *

modsec = ModSecurity()
#s = “Hello World, I am: “ + str(modsec.whoAmI())
#print s
rules = Rules()
r = rules.loadFromUri(“/path/to/your/v3.0.0-dev/rules/REQUEST-10-IP-REPUTATION.conf”)
if r == -1:
    print rules.getParserError()
    sys.exit()

i = 0
while i < modsec.NUMBER_OF_PHASES:
    r =  rules.getRulesForPhase(i)
    print "-- Phase " + str(i)
    for x in r:
        if x.rule_id == 0:
            continue

        print "    Rule Id: " + str(x.rule_id)
        print "       From: " + str(x.m_fileName) + " at " + str(x.m_lineNumber)
    i = i + 1

Script 4. Print all rules ID from a ModSecurity configuration file. 

The output of Script 4 should appear similar to the output illustrated below in Figure 3.

 Figure 3. The output of the script which prints the rules ID in the console.

Of course this script can be extended to print this information in any manner desired. A slightly more refined example is illustrated in Figure 4. Remember that as this is Python it is easy to display this information as part of GUI or web application.

 Figure 4. ModSecurtity rules information extracted using the libModSecurity parser, inside a Python script.

Conclusions

The new ModSecurity Python bindings should make it easy and fast to utilize libModSecurity as demonstrated in the examples above. These Python bindings are just one of a host of new features we will be presenting in upcoming blog posts, so be on the lookout.

The advantage of fast prototyping provided by the script language utilization, plus, the performance of a core in C++ opens a wide range of possibilities. Like the construction of a Rule editor in Python, and/or a Django web application to navigate inside the rules. In fact, why not implement those as open source projects?

Notice that those are just simple examples, but it is just as easy to use these bindings to actually process a transaction, but this is left as exercise for the reader, enjoy :)

Exploring GSM Vulnerabilities to Assess Mobile Users' Location

The privacy of about 5 billion GSM users worldwide is exposed. Their location is available to eavesdroppers while society keeps attention to vulnerabilities in software layers which may compromise the privacy of a very select group of users. The GSM networks depend on the mobile phones location to provide a good service. That dependency is intrinsic to the GSM protocol, where the phone must be near to an antenna in order to ensure a good radio signal quality between the mobile phone and the Base Transceiver Station. Unlike social networks or other Internet services where the users need to explicitly authorize the sharing of information about their location, the GSM protocol does it ubiquitously.

Using as excuse my master's degree, in the past years I've been fully entertained studying/researching about some GSM vulnerabilities that may expose the geolocation of users. During the work I've studied known vulnerabilities and I also made some patches on known GSM security tools which may be very handful to reproduce the experiments I've made to prove my point.

My work was divided into three different ways to assess the user geolocation, they are unrelated but information gather in one may be useful to others attacks. These three different attacks intend to collect the victim geolocation in the following accuracy levels: country, portion of the city and neighborhood. This may vary depending on the provider configuration. So, do not expect this to work on all cases.

To illustrate the attacks we use two different entities: the attacker and the victim. For the second and third attacks, besides knowing the mobile number of the victim,  the attacker also needs to have two OsmocomBB compatible mobile phones and some specific OsmocomBB patches that are explained in this post. For the first attack, the attacker just need to have an account in an HLR provider and, of course, the mobile number of the victim.

First attack, Country

By knowing the telephone number of the victim it is possible to track down its country of origin by the phone prefix. It is also possible to know if the number still valid, working and if the user is in roaming or not. If so, which country the user is.

All this information can be gather using an HRL query provider. Note, however, that just some providers are leaking such information. In some countries (like Brazil) the providers are not able to leak this information, due law enforcement. In the map bellow is possible to identify in which countries the information is available (in green) or not (in orange).

Depending on your HLR provider, the information about the country comes already parsed, as illustrated in the example bellow.

As further work, the MSC gateways could be used to map the geolocation of the users, however, a mapping of the region is needed to be done prior to the attack.

Second attack, Portion of the city

This attack relays on the fact that a mobile phone is always connected to a BTS, listening a broadcast channel which belongs to a virtual group called: LAC. Knowing that, the attacker can address some demand (SMS or call) to the victim phone number and wait to see the victim identification (IMSI or TMSI) being redirected by the network to an specific channel/time slot to receive the demanded content. Broadcast channels are always delivering messages to users, more than one per second which makes impossible to the attacker to identify the victim TMSI or IMSI in the first try, so subsequent attempts need to be made reducing a `possible-victim list`, narrow it to one if the victim is part of a LAC or zero if the victim is not part of it.

Bellow there is a graphic of my hometown, Recife, with the LACs in different colors. It gives us an idea how big the LACs are and consequently the accuracy of the attack.

Third attack, Neighborhood

This last attack is the one with the best accuracy. The idea is based on the fact that a SMS or a call will be delivered faster between two members of the same BTS/Tower. In different towers the message will be delivered from one tower to another and so one, until it reaches the final destination. By having the two phones on the same BTS, the message will be delivered directly to the destination as soon as it hit the tower.

Similar to the second attack, the ID of the victim on the network should be revealed before anything. After that, the attack jumps from tower to tower verifying the amount of time that the network takes to send the victim to a proper time slot/channel to receive the message.

The coverage area of a BTS may vary, it tends to be bigger in rural areas, with lower phone density and smaller in downtown, bellow is illustrated the area of coverage from BTSs in my hometown. Where F and E are the biggest and the smallest coverage area. Its sizes can be found on the table bellow.

Conclusion

Those problems are not new, they have been discussed for a while. The idea of this post was to give short intro about the subject by exposing the vulnerabilities.

All these hypothesis were proved on my dissertation. For further reading, including tests, have a look on my dissertation available here.

For information about the ways to circumvent or minimize those problems, fire me an e-mail.

AppArmor D-Bus Mediations

Looking like the SELinux but less boring, the AppArmor is a Linux security module (LSM) which provides mandatory access control (MAC). The first distro to adopt the utilization of AppArmor was SUSE in SUSE Linux Enterprise Server 10 and in openSUSE 10.1. It is part of Ubuntu since the version 8.04 and the adoption increase version to version since more profiles are created.

Other software that is part of more and more applications each day is the D-Bus, adopted by GNOME and KDE as an inter-process communication mechanism, the usage of D-Bus allows the communication between different applications. It is used, for example, to provide the communication between a software Core with the UI. Due to the nature of the communication of certain applications (sensible data) is indispensable to have some control about who can acquire some interface or who can listen or send some message.

D-Bus daemon has support to mediate SELinux messages and there is also a D-Bus internal mechanism that has some control over the use of the bus, but none of this is related to AppArmor. There are some experiments that show that it is possible however the necessary patches (Kernel, libapparmor and D-Bus daemon) were not submitted to be part of the respective projects, as explained in the earlier post.

The patches on the experiment enable apparmor parser to understand the tag dbus, as illustrated on the example bellow (line 15). More information about the experiment and the syntax of the file can be seen in: https://lists.ubuntu.com/archives/apparmor/2011-September/001541.html

/home/zimmerle/hello.py flags=(complain) {
#include <abstractions/base>

/usr/bin/python2.7 ix,
/usr/include/python2.7/pyconfig.h r,
/usr/local/lib/python2.7/dist-packages/ r,
/usr/share/pyshared/PIL.pth r,
/usr/share/pyshared/lazr.restfulclient-0.11.2-nspkg.pth r,
/usr/share/pyshared/lazr.uri-1.0.2-nspkg.pth r,
/usr/share/pyshared/pygst.pth r,
/usr/share/pyshared/pygtk.pth r,
/usr/share/pyshared/ubuntu-sso-client.pth r,
/usr/share/pyshared/ubuntuone-client.pth r,

dbus bar.foo.hello acquire,
}

In order to ensure the functionality of the suggestion made in the post: D-Bus Loadable security module support, I decided to modify the AppArmor D-Bus daemon patches to make them compatible with the suggested model. And it is working like a charm.

The code of the current experiment can be fetched from:

http://cgit.collabora.com/git/user/zimmerle/dbus-apparmor-lsm.git/

Note that in this experiment I had to use the D-Bus internal functions/headers. I made little hacks in order to get it working but apparently, this is a good way to go.

D-Bus Loadable security module support

While I was thinking about LSM mediations of the D-Bus messages, I found out a nice work that is being developed by the Ubuntu sec team in order to support the AppArmor mediation on D-Bus message exchange and service acquisition.

Having a chat with John Johansen (from Unbuntu sec team), he said that he was missing a loadable module support on the D-Bus. Allowing the support of different Linux Security Modules mediation without messing up the D-Bus daemon code, which does make sense.

I started to implement a little PoC about this loadable support, which consists in the following: the LSM modules can be dynamically loadable at the d-bus daemon startup. By copying a D-Bus LMS module to a given directory (which can be specified at the d-bus configuration) it will be loaded and registered.

The idea is to have independent modules, if possible use only the D-Bus functions provided by libdbus, however, of course, if needed symbols can be copied from libdbus-internal.a.

Despite the fact that the modules can be independent of the D-Bus internals, they must have at least one known function, this function should be named as “pre_init“, and receives the pointer to the D-Bus internal function “register_security“. The “register_security” function should be called by the module if it is loaded successfully. The “pre_init” function must return a “dbus_bool_t“: true if everything goes right or false if not. Note that audit can be also initialized by this function.

The function “register_security” receives as parameter a pointer to the structure “security_validations” that is part of dbus-security.h. The structure is illustrated bellow:

struct security_validations
{
 char *name;
 dbus_bool_t (*bus_security_allows_send) (DBusConnection *,
                                         DBusConnection*,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         const char *,
                                         DBusError *);
 dbus_bool_t (*bus_security_allows_acquire_service) (DBusConnection *,
                                                    const char *,
                                                    const char *,
                                                    DBusError *);
 dbus_bool_t (*shutdown) (void);
};

The structure “security_validations” defines the hooks and the name of the security module and also the function to shutdown the mediation. Two main hooks were needed, the first is the one responsible to mediate the message exchanges and the second is the responsible to avoid unauthorized process to acquire some service. The shutdown hook is not less important, but less used. Shutdown is only called when the D-Bus daemon is hanging out.

The current implementation of SELinux mediation needs more hooks to work than what I am offering in this PoC. Since the SELinux implementation has some performance improvements by doing caching, it will be necessary to create new hooks to gather some information before deciding whether some message is ok to go or not, but this may be a later discussion.

The patched D-Bus code is available at:

http://cgit.collabora.com/git/user/zimmerle/dbus-lsm.git/

And there is a dummy module at:

http://cgit.collabora.com/git/user/zimmerle/dbus-dummy-lsm.git/

No eXecute and Atom, the current MeeGo state

The security of your box goes over the firewall, or the fact that you are running a platform where all binaries are trusted. Even on that case, is still possible that vulnerabilities of some software or library could be exploited by a malicious party.

The idea behind the NX bit, No eXecute, is to segregate the areas of the memory in two (lets keep it simple :P) big sets, the code execution area and the storage area. According to Wikipedia (http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors), the Atom family has the capability to handle such bit.

Adding this feature and a Linux kernel, is possible to avoid the execution of code in the data area, protecting the system against buffer overflows attack. However some marks should be placed on ELFs to archive such protection, these marks are made in the ELF construction and they can mark the ELF to have or not an executable stack. In the second case the executable flag has no effect, is useless.

The marking can also be made on a library (it is also an ELF, duh!) and when this happens, the software which loads that library will be also allowed to run code inside the data segment, disabling again the protection against buffer overflow.

To check the executable marks of your ELFs, you can use the pax-utils (http://www.gentoo.org/proj/en/hardened/pax-utils.xml). Running the tests on a daily MeeGo image (2010-22-07) the following results were archived:


[root@localhost ~]# scanelf -lpqeR
RWX --- --- /usr/lib/libmono.so.0.0.0
RWX --- --- /usr/lib/paxtest/getmain2
RWX --- --- /usr/lib/paxtest/getheap2
RWX --- --- /usr/bin/mono

This means that libmono and mono, for some reason, are expected to run code on the data segment of the memory. In Fedora the mono is marked as RW, I dunno why it is marked as RWX in MeeGo, further investigation should be done.

Mono’s GNU_STACK on Fedora:

(zimmerle@burbs)-(~/core/meego)$ readelf -l /usr/bin/mono | grep GNU_STACK
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000

Is acceptable to have some process without such kind of protecting, for example Java. Java depends on the executable stack to work. It is also acceptable to have some other binaries like: getmain2 and getheap2. These are used to test if the Machine is handling well the NX bit.

To check if your platform has handled well the support of the NX bit, you can use the pax-test, really nice utility that allows us to check the protection against various kinds of exploration. Tests were also made on the same release used above.

kidde mode:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux localhost.localdomain 2.6.35~rc6-131.2-netbook #1 SMP PREEMPT Tue Jul 27 14:34:50 UTC 2010 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 10 bits (guessed)
Shared library randomisation test : No randomisation
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable

blackhat mode:

PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux localhost.localdomain 2.6.35~rc6-131.2-netbook #1 SMP PREEMPT Tue Jul 27 14:34:50 UTC 2010 i686 i686 i386 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 10 bits (guessed)
Shared library randomisation test : No randomisation
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Vulnerable

As you can see, we are protected against code execution in any other area than that intended for this purpose. We don’t have randomization on libs due the fact that we are making use of the prelink, subject for another post .

The pax-utils and pax-test pacakges can be found on my security MeeGo repostiory, at:

http://meego.zimmerle.org/repo/security/

If you are interested in testing it by yourself, you can download my ks file here.

That kind of protection is very important almost mandatory, modern system still been hacked by such kind of attack class, when they opt to not provide such protection, the case of Xbox, for example which is exposed to a vulnerability in the 007: Agent Under Fire (http://en.wikipedia.org/wiki/Agent_Under_Fire_(video_game)).

Poulsbo support on MeeGo, almost there

This is a continuation of my last post about Poulsbo support on MeeGo. A lot of people have asked me to continue this work, but I just had time today. In this post I will talk about the Xorg drivers. After some research/reading these sites:

• http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/x11-driver-video-psb/


• http://code.google.com/p/gma500/


• http://www.happyassassin.net/2010/05/21/video-acceleration-and-poulsbo-news/


• https://edge.launchpad.net/~gma500/+archive/fix

And after some work, I created/built the necessary packages to get the Poulsbo Xorg driver working on MeeGo. The performance differences are notable.

I got my netbook running MeeGo with the Xorg driver, but without 3D acceleration yet, meaning, it still slow. The Intel closed 3D driver is already packed and installed but for an unknown reason when I enable it the Xorg just crash. Further investigation is needed.

I had to place “suid” bit on Xorg to make the driver work correctly. All the necessary packages to make it work can be found on my megoo repo, and also there is an image available if you want to check it out.

You can download the image via torrent or directly from my site: iso image. The ks file goes here.

And here is a nice picture of my netbook running the MeeGo official UI:

[Update 2016-12-26] Mandriva's svn repositories are no longer available. For further information check (external link): http://www.whoishostingthis.com/resources/mandriva/