Subreption blog

Tue, 16 Sep 2008

Futile attempts and the joy of locked down Apache processes

Apparently someone, in his glaring innocence, is playing around Apache. Possibly we should start looking at mod_python or maybe mod_ssl. Maybe we can just let RBAC and PaX take care of it. But abuse departments are extremely responsive these days! One wonders what these people think when they have their DSL lines shut down.

Sep  8 16:42:21 vmsrv21 grsec: From 65.190.223.67: signal 11 sent to /usr/sbin/apache2[apache2:28215]
Sep  8 16:42:21 vmsrv21 grsec: From 65.190.223.67: signal 11 sent to /usr/sbin/apache2[apache2:28215]
Sep  8 16:42:21 vmsrv21 grsec: From 65.190.223.67: signal 11 sent to /usr/sbin/apache2[apache2:28934]
Sep  8 16:42:21 vmsrv21 grsec: From 65.190.223.67: signal 11 sent to /usr/sbin/apache2[apache2:28934]
Sep  8 16:42:21 vmsrv21 grsec: From 65.190.223.67: signal 11 sent to /usr/sbin/apache2[apache2:28922]

The grand official Idiot of the Month, for your amusement. You might find it useful to add his IP range to your preferred spam blacklist as well. And another prop to spender for the brute force prevention feature of grsecurity, which makes exploiting re-spawning daemon vulnerabilities a hell more boring and futile. Especially when you have 40 bits of ASLR on your side. Yikes!

OrgName:    Road Runner HoldCo LLC 
OrgID:      RRMA
Address:    13241 Woodland Park Road
City:       Herndon
StateProv:  VA
PostalCode: 20171
Country:    US

ReferralServer: rwhois://ipmt.rr.com:4321

NetRange:   65.184.0.0 - 65.191.255.255 
CIDR:       65.184.0.0/13 
NetName:    RR
NetHandle:  NET-65-184-0-0-1
Parent:     NET-65-0-0-0-0
NetType:    Direct Allocation
NameServer: DNS1.RR.COM
NameServer: DNS2.RR.COM
NameServer: DNS3.RR.COM
NameServer: DNS4.RR.COM
Comment:    
RegDate:    2004-04-07
Updated:    2005-05-16

OrgAbuseHandle: ABUSE10-ARIN
OrgAbuseName:   Abuse 
OrgAbusePhone:  +1-703-345-3416
OrgAbuseEmail:  abuse@rr.com

OrgTechHandle: IPTEC-ARIN
OrgTechName:   IP Tech 
OrgTechPhone:  +1-703-345-3416
OrgTechEmail:  abuse@rr.com

Published on: Tue, 16 Sep 2008. | Path: /security/exploits | Permalink

Thu, 11 Sep 2008

Marshal and Native API bridging on Microsoft Windows (NT)

The .NET framework provides a Marshal class from its Runtime.InteropServices namespace which helps interfacing native and unmanaged data with managed code. The easy path for most of these cases is to simply use unsafe blocks and cast a pointer, but you end up losing references to allocated structures, leaking memory and likely leaving some funny exploitable condition in your unmanaged code bridge. Those pesky dangling pointers...

The function below calls an internal method to retrieve the list of loaded kernel modules from userland. It depends on NtQuerySystemInformation() and requires a heap-allocated structure array. Interfacing this with a C# managed class will require another exported function to call HeapFree() and release the allocated memory.
Using such an approach is certainly not recommended but it will cut you some hassle:

extern "C" __declspec(dllexport) PSYSTEM_MODULE_INFORMATION GetKernelModules(void)
{
	HANDLE tmpHeap = GetProcessHeap();
	PSYSTEM_MODULE_INFORMATION modList = NULL;
	
	LoadFunctionPointers();
	_getSysModules(&modList, tmpHeap);

	return modList;
}

extern "C" __declspec(dllexport) void MyFreeHeap(LPVOID ptrToFree)
{
	HeapFree(GetProcessHeap(), HEAP_NO_SERIALIZE, ptrToFree);
}

On the C# side, we will be using a Marshal structure declaration in order to be able to use the PtrToStructure method, which allows us to copy memory from unmanaged space into our managed class, and then we can release whatever memory was allocated for the native API.

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 2)]
public struct SYSTEM_MODULE_INFORMATION
{
    [MarshalAs(UnmanagedType.U4)] public UInt32 Reserved1;
    [MarshalAs(UnmanagedType.U4)] public UInt32 Reserved2;
    ...
}

int curOffset = (int)(i * Marshal.SizeOf(Modules[i]));
IntPtr curPtr = new IntPtr(ModulesListPtr.ToInt32() + curOffset);

Modules[i] = (SYSTEM_MODULE_INFORMATION) Marshal.PtrToStructure(curPtr,
                   typeof(SYSTEM_MODULE_INFORMATION));

[DllImport("mylib.dll", CharSet = CharSet.Unicode)]
        private extern static void MyFreeHeap(IntPtr ptr);

Depending on your target platform, you might want to adjust CharSet since Unicode is the default on NT based systems (that is, all modern versions of Windows, excluding 9x/ME if you consider them modern... although in terms of security, it seems like Windows 98 is safer, after all, most malware doesn't work on it anymore). Packing is also important, since it means how your structure is actually stored on memory. Values of 1-2 are safe, just verify the alignment of the variables within the structure you are trying to use.
Some suggestions:

In your bridge DLL, don't resort to typical pointer overwrites to return or store information to the calling function. Using GCHandles to deal with such functions will cause a great deal of stupid exceptions about incorrect references in the internal GC object tracking. Let's say that .NET GC does not like to release handle with wrong pinned object addresses. Save you some debugging time, and in the meanwhile, do proper unmanaged programming.
Your bridge DLL should allocate heap memory and set or return a pointer to that location. Then your managed class should call a pInvoke or similar method that itself works with HeapFree within your DLL bridge library. You could also use Marshal.AllocHCGlobal
Use a GCHandle when you need to write data from your unmanaged code directly, and remember to release it once you are done with it. But never overwrite the address of managed object or you will end up hitting an invalid free whenever the GC attempts to release your now corrupted object. And that might happen in a manner that makes debugging a pain in the ass. Better go clubbing than waste your time debugging that.

Published on: Thu, 11 Sep 2008. | Path: /programming/csharp | Permalink

Wed, 10 Sep 2008

Alice in Wonder-setuid-emacs-land (CVE-2008-2324)

One may think that vulnerabilities can't get any more stupid, but there's always an Apple advisory to beat the record. A setuid Emacs binary? Seems like a plan. (From APPLE-SA-2008-07-31 and CVE-2008-2324).

Disk Utility
CVE-ID:  CVE-2008-2324
Available for:  Mac OS X v10.4.11, Mac OS X Server v10.4.11
Impact:  A local user may obtain system privileges
Description:  The "Repair Permissions" tool in Disk Utility makes
/usr/bin/emacs setuid. After the Repair Permissions tool has been
run, a local user may use emacs to run commands with system
privileges. This update addresses the issue by correcting the
permissions applied to emacs in the Repair Permissions tool. This
issue does not affect systems running Mac OS X v10.5 and later.
Credit to Anton Rang and Brian Timares for reporting this issue.

The "Repair Permissions" tool should have been removed from Mac OS X a long time ago.

Published on: Wed, 10 Sep 2008. | Path: /security/apple | Permalink

Sat, 06 Sep 2008

The blog is back and rolling on Python

Finally the blog is back, after many changes in the infrastructure behind the scenes. The most important move was removing PHP support in our servers and migrating from Wordpress as blogging engine. Unfortunately, the current state of security for web applications developed with PHP and the language itself, is simply not acceptable for most people with above average security requirements.

Most PHP web applications use inherently flawed preg_replace() calls.
Wordpress and most PHP web applications are oblivious to multibyte character encoding issues: there are potential execution paths that could be abused using special encodings. For instance, they were never developed with such corner cases in mind.
mod_php itself is a memory blackhole. Only FastCGI environments can provide a minimally acceptable level of security when it comes down to privilege separation and memory address space isolation. As an example, check how mod_php let's a PHP script access Apache's file descriptors. It's just stupid.
While other languages such as Python and Ruby suffer of common vulnerability classes (from the most trivial cross-site scripting to CSRF et al), PHP brings its own tricks.

We are now running on a full Python and Ruby infrastructure with isolated jails and few critical services virtualized. PaX and grsecurity RBAC policies provide the necessary fncitonality to ensure that every process is locked down properly. Besides, PaX on 64-bit processors provides a whopping 40-bit ASLR entropy :).

Published on: Sat, 06 Sep 2008. | Path: /blogging | Permalink

Pyblosxom and mod_wsgi benchmark

Running our custom pyblosxom engine with mod_wsgi and Apache disk-based cache enabled is currently providing a performance of roughly 170 requests per second as of a measurement running 50 concurrent requests and a total of 1000 requests against the index page as of 6th September 2008.

There are some potential improvements and lighttpd or a similar high performance webserver could probably beat these numbers by a magnitude of a few thousand requests. We will be likely testing such a setup in the future. In our tests, lighttpd itself can handle around 1012.06 requests per second for a FastCGI served lightweight PHP script with no database backend usage.

Server Software:        Apache
Server Hostname:        blog.subreption.com
Server Port:            80

Document Path:          /hub
Document Length:        24112 bytes

Concurrency Level:      50
Time taken for tests:   5.882 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      24289000 bytes
HTML transferred:       24112000 bytes
Requests per second:    170.02 [#/sec] (mean)
Time per request:       294.088 [ms] (mean)
Time per request:       5.882 [ms] (mean, across all concurrent requests)
Transfer rate:          4032.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:    17  287  51.1    299     490
Waiting:       16  286  51.2    298     490
Total:         18  287  51.0    299     491

Percentage of the requests served within a certain time (ms)
  50%    299
  66%    313
  75%    321
  80%    325
  90%    338
  95%    351
  98%    368
  99%    375
 100%    491 (longest request)

Published on: Sat, 06 Sep 2008. | Path: /opensource/performance | Permalink