We are proud to announce the immediate availability of HITB Magazine Issue – The first HITB Magazine release for ! HITB Magazine. Cover Story Windows Security Windows CSRSS Tips & Tricks Linux Security Investigating Kernel Return Codes with the Linux. Full text of “Hack In The Box Magazine – Issue ” Co A very Happy New Year and a warm welcome to Issue 05 – The first HITB Magazine release for 1!.
|Country:||Turks & Caicos Islands|
|Published (Last):||20 April 2011|
|PDF File Size:||16.40 Mb|
|ePub File Size:||13.59 Mb|
|Price:||Free* [*Free Regsitration Required]|
Search the history of over billion web pages on the Internet. Just over a year has passed since Issue and 0 was definitely a great year for our humble magazine with over adownloads of the 4 issues released which included 24 unique technical articles authored or co-authored by over 30 security experts from around the world!
Since April 0, readers have also had an opportunity to get familiar with prominent figures from the IT security industry thanks to the new “Interviews” section. We believe our goal of “giving researchers further recognition for their hard work, and to provide the security community with beneficial technical material” as stated in our editorial note of Issue has been successfully achieved.
All this however, wouldn’t issie be zeine without YOU – our loyal and supportive readers! As always, feedback of any kind is greatly appreciated so don’t hesitate to drop us a line if you have any suggestions or comments.
See you there and in the meantime, enjoy the issue! Matthew “jOOru” J urczyk http: If they had bad intent, they would probably consider ways to elevate privileges.
The kernel is a ubiquitous place to attack because even if you are chroot’ed, the syscall interface is still available. To successfully attack the kernel using the syscall interface, someone would usually issuw advantage of a syscall issye does not verify its 005 correctly. One of the easiest ways to find weak validation is to use syscall fuzzers.
Practical Information Security: HITB Magazine Issue #5 is now available
You just turn it loose and wait for the crash. Some people see a kernel “oops” as a Denial of Service. Others see it as a NULL function pointer dereference that could call code in user space if it were mmap’ed to page 0.
In other words, if you are not thinking about how to exploit a problem, you may not realize its consequences. As a result, many serious kernel security problems are misclassified and therefore under-reported. One of the ways to protect against this form of attack is to intercept syscalls and perform a verification of the syscall parameters before letting the data into the kernel. This is a simple technique that is used by some commercial security products. This made me wonder if there were any Open Source kernel modules that do the same.
If not, that might be an dzine project to start. The theory is that if the kernel really did thorough data validity checking before accepting it, we might be able to catch malware as it tries kernel exploits.
But I’ve had enough dealings with kernel developers that I’m certain they would tell me to go spend some time reviewing each and every syscall and make sure that the kernel is sanity checking parameters before using them. It would take less time to implement since most syscalls do checking and ultimately, its the Right Thing to do.
If the kernel were completely cleaned up so that every syscall was correctly rejecting invalid parameters, where does that leave the commercial products that do this? What are they offering that doing the Right Thing wouldn’t cover? The answer, Iseue think, is auditing. The value add is that whenever wzine attempts to subvert the kernel, its logged eznie possibly alerted.
That leaves the question as to how good is this technique. What problems, if any, would prevent use of this method of detecting attacks? Sure there are other errno return codes with more specific meaning about why the parameters are bad, but I hitn just wanting to check if this approach works or not.
The Linux Audit system sits in the kernel and can log events that match predetermined conditions. It also has a set of utilities that make review of the findings eaine simple. As far as any program is concerned, it does not actually return. The return code that the audit system would see is the value isdue the AX register which could have false positives. So, its best to exclude this syscall 005 the results.
The second rule means that for every Linux syscall, when it exits always create an event if the exit code from the kernel would be EINVAL and insert the “key” or text string “einval” into the event so that its easy to find later. I let this run a few days and then ran this search: Later in the investigation we will use some of its other options to make the output nicer, but we’ll go over them here. If you pass’-i’to it, it will take some of the numeric data that the kernel understands and turn it into something more human friendly.
The ‘-raw’ option tells it not to do post- processing of the output. This is necessary to pipe the information into something that can further analyze the output like aureport. The ‘–just-one’ option extracts only one event which is desirable when there could be many. The ‘-sc’ option can match events for a specific syscall. And lastly, the ‘-x’ option will match against a specific executable name. The aureport program is designed to provide summary and columnar formatted data from the audit logs.
Useful reports for this investigation are the executable report by passing the ‘-x’ option and the syscall report by passing a ‘-syscaN’parameter.
Some useful options that help analysis is the ‘-summary’ parameter which tells it to create a numeric total of important data for the given report and sort its output from most to least. Another useful option is the ‘-i’ parameter which functions just as the ausearch interpret parameter did. We will take a look at current Fedora and older Fedora releases because they are informative in how to conduct and investigation and some of the same problems showing up in current releases.
With regards to the search listed above, I had quite a few hits on a Fedora 9 system. So I decided to pass the output to aureport to make it more user friendly. On the one hand, you can see how powerful the audit system can be for tracking down issues like this, but on the other hand you have to wonder how well this syscall parameter validation works for commercial Intrusion Detection Systems.
With this many hits, you’d imagine they would have to create all kinds of loopholes to prevent false alerts for typical programs a user may need during a session. For the technique of sanity checking syscall parameters to be useful for finding attempted exploits, all the software on the system must be clean and not this noisy. Too many false positives weaken its reliability.
This may lead the reader to wonder ezlne would normally working programs be constantly creating kernel errors? I felt this merits more digging. Let’s see all the syscalls that are being called with invalid arguments: This is encouraging in that we can probably do root cause analysis and clean these syscalls up so that one day an IDS system might look for failing syscalls and not need so many loopholes.
Let’s take a look at how the Fedora 10 system compared using the same syscall summary report: Fcntl and Iseek are not a problem in Fedora 1 0. But now let’s see how the current Fedora 14 system compares with the same report: So historically the trend is getting better.
One item helping this is the Linux kernel updated the capget syscall to allow querying the kernel’s capability protocol without returning an error.
This means that loopholes created to prevent false alerts on Fedora 9 would have to iwsue changed for Fedora 1 0 and changed again for Fedoar 1 4.
HITB Magazine Volume 1 Issue 5
By extension, I think its likely that policy for Fedora may not be an exact fit for Ubuntu or OpenSuse since each distro releases at different times and slightly different versions of key software. But getting back to the root cause of these failing syscalls, we will take a look into each of them and see if we can pinpoint the exact cause and suggest a fix so that the OS is less noisy to using this Intrusion Detection technique.
We will start by looking at one of the new Fedora 14 syscall problems and then look at the older releases. We will then dig into the source code to identify the bug if possible and recommend a corrective action.
To find out what programs are misusing the syscall, lets use the following search: Let’s take a look at how one of those programs is using the syscall with the following query: The fields aO through a3 show the first 4 arguments to the listed syscall. In the event that a syscall doesn’t have 4 parameters, just don’t look at the extra ones. The Linux audit hitv is not designed to capture any syscall arguments past 4 and does not record them.
It should also be noted that the argument values are recorded in hexadecimal. Looking The nitb looks like this: In some cases this error can also occur for an invalid value in optval e. The code as written does not make any attempts to avoid the illegal signal numbers.
This code should be rewritten as follows: So digging into the code for util-linux- ng I would suggest that the code be rewritten to have: Looking at the audit events: Digging into the source code, in virtuoso- opensource So, what could be wrong in virtuoso? Lets see what its ezin structure is. I think the code should be amended to use kernel structures so that its portable should the tv structure ever change. First let’s look at the man page’s explanation of return codes for this syscall: Then we need to look at the syscall captured by the audit system.
That would not be a valid descriptor for wd. A quick review of the exe isse in the event shows all the problems are with the restorecond program which is part of the SE Linux policycoreutils package.
Let’s take a look in its source code. The problem seems to originate here: But we also find that the program has a debug mode that outputs the descriptors and the path its watching: To fix this problem, the return value must be checked when creating the watch and not add libflashplayer to its linked list of watches when there is an error.
The funny thing is that the return code is not checked and there is a lot of code executed after this syscall assuming that the Iseek went OK.
To clean this up, one would need to find the size of the file system with something like fstatfs and then if the Iseek offset would be greater, don’t do it. But if it were OK to lssue the Iseek, you would certainly want to check the return code before continuing. Its pulled from the audit logs like this: