Georgi Guninski's blog

Closed vs open source in light of the windows leak of 2020-09-25

There is debate which is more secure: closed or open source.

Since the answer is very complicated and depends on many factors, we are over simplifying things.

On 2020-09-25 microsoft's windows source leaked [1].

Closed source advocates claim closed source is more secure, since the closed is secret.

Q1: To what extent the m$ leak disproves the above claim about secrecy?

XXXfix

Assume that in the near future the number of m$ vulnerabilities:

1. Greatly increase or
2. Stay at the same level or
3. Greatly decrease XXX?

Could this be related to the leak and what conclusions follow?

1 2

From the history of Microsoft (part 1)

by Georgi Guninski Sat 03 Oct 2020 08:51:30 AM UTC, version 1.0.1

History is written by the winners, so here we write:

• Microsoft accidentally distributes virus July 28, 2002

The software giant's Korean-language version of Visual Studio .Net carries the virulent Nimda computer virus to Asia.

• Ballmer: 'Linux is a cancer' Sat 2 Jun 2001

Contaminates all other software with Hippie GPL rubbish. Microsoft CEO and incontinent over-stater of facts Steve Ballmer said that "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," during a commercial spot masquerading as a interview with the Chicago Sun-Times on June 1, 2001.

• Halloween documents: August 1998 - March 2004.

The Halloween documents comprise a series of confidential Microsoft memoranda on potential strategies relating to free software, open-source software, and to Linux in particular, and a series of media responses to these memoranda. Both the leaked documents and the responses were published by Eric S. Raymond in 1998.

• Bill Gates is an android user: 26 Sep 2017

%RIP Windows Phone, we are not crying much.

• Weird garbled Windows 7 update baffles world – now Microsoft reveals the truth: 30 Sep 2015

Its description mostly contained garbled text. Links for more information, help, and support were filled in with gibberish URLs with ".gov," ".mil," and ".edu" domains.

• m$ is linux vendor: 27 Jun 2019

2001: Linux is cancer, says Microsoft.

2019: Hey friends, ah, can we join the official linux-distros mailing list, plz?

We tried to speak up, the oss vendor crowd liked m$.

• Closed source, source leaked and widely open. Possibly to fit Microsoft better in the so called open source community, unknown forces leaked m$' sources. MS hacked! Russian mafia swipes WinME source? 27 Oct 2000

On 2020-09-25 leaker billgates3 wrote, adding insult to injury:

"I created this torrent for the community, as I believe information should be free and available to everyone, and hoarding information for oneself and keeping it secret is an evil act in my opinion," the leaker said, adding that the company "claims to love open source so then I guess they'll love how open this source code is now that it's passed around on BitTorrent."

She: Did you know your gmail password reveals your personality?
He:  Really? My password is: E!=m*c^2 NSFW sha gi iba
She: Your personality type is INTP.
He:  This can't be, assembler interrupts INT take numeric argument.

Some remarks:
1. We have seen NSFW passwords on the internetz.
2. INTP exists.
3. Assembler interrupts really take numeric argument.
4. sha gi iba is not very random is certain language.

Exploitability of the integer overflows in djbdns 1.05?

TLDR: Are the integer overflows in djbdns 1.05 exploitable?

Background: there are integer overflows and memory corruption
in the library functions of qmail 1.03.
For reference see [1] [2].

Some of the qmail vulnerabilities (integer overflows and negative index???)
are present in djbdns 1.05.

For example in alloc.c of djbdns:
====
/*@null@*//*@out@*/char *alloc(n)
unsigned int n;
{
  char *x;
  n = ALIGNMENT + n - (n & (ALIGNMENT - 1)); /* XXX: could overflow */
=====

This clearly overflows for n= -1 for example.

It is natural to write an integer overflow, but
documenting easy to fix security bug is beyond
our understanding.

Reachability of the bugs is not clear and might require
gigabytes of memory to hit the problems by encoding
integer in unary.

In addition djbns limits the memory usage by |softlimit|,
but we are not sure the limits are on all vulnerable
programs. An island of tractability could be |alloc(atoi())|
or |alloc(size * count)|

Is djbdns exploitable by any of the qmail bugs?

[1] http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
[2] https://www.openwall.com/lists/oss-security/2020/05/19/8

Short notes on qmail security guarantee

Disclaimer: written in hurry, could be wrong.

djb offers monetary bounty for verifiable qmail exploit,
called "qmail security guarantee" [1].

He hasn't awarded the bounty yet, despite several
vulnerabilities found by us in 2005 [2] and in 2020 [3]
Qualys discovered that at least one of the vulnerabilities
works in default qmail install.

Both of these vulnerabilities require more that 4GB memory.

djb's main argument is that nobody gives a lot of memory
to qmail-smtpd (and as djb might missed to all other
qmail- components).

We believe that the claim of memory limit is wrong for
the following reasons:

1. qmail's install documentation doesn't mention memory limits
2. Qualys claims that their exploit works on the default
install of all packages they have seen (and all package maintainers
have missed memory limits).
3. djb shouldn't assume that 4-8GB will be enough for the
normal functioning of qmail. In theory libc might require
more RAM in the future. Currently mobile phones have
32+GB RAM and there is clear trend in grow of RAM.
4. By common sense, distributing software with known vulnerabilities
is bad practice.
5. AFAIK djb teaches students about coding and security and he
better lead by example of good coding.

[1] https://cr.yp.to/qmail/guarantee.html
[2] http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html
[3] https://www.openwall.com/lists/oss-security/2020/05/19/8

There is conspiracy theory that Bill Gates is related to the
Corona Virus, search the web. We believe this theory is false,
but Bill is responsible for the catastrophic epidemy Windows.
Hopefully the Windows epidemy will vanish, mainly due to the androids
and other viruses eating it.

Shell wildcards considered dangerous?

Remote version of this affects wu-ftpd from 2003:
https://www.debian.org/security/2003/dsa-377

Summary:  For trusted command PROGRAM, executing
PROGRAM *.EXT
may lead to arbitrary code execution, e.g. for 
PROGRAM=EXT=tar

The main idea is the wildcard to add program options.

Open problem: 

Are popular programs other than tar vulnerable?

Since shell wildcards are unlikely to change, should best practice
include not using *.EXT in shell?


Example exploit vector: starting program in untrusted
directories.

Poc:
====
$rm -rf /tmp/1 ;mkdir /tmp/1 ; cd /tmp/1 ; tar cf a.tar /etc/issue  
$ : >  --to-command="yes .tar"

#end creating, starts PoC
tar xf *.tar

#.tar (repeats)
====

Mitigating malicious packages in gnu/linux

As end user and contributor of gnu/linux, I am concerned about malicious packages (either hostile developers or hacked developers or another reason) and have two questions:

• What do linux vendors to avoid malicious packages?

• As end user what can I do to mitigate malicious packages?

Some thoughts and rants:

1. This already happened in 2003 with the micq package in debian: unnoticed easter egg causing DOS, see [1].

2. This already happened to Redhat in 2008? see [5], Red Hat OpenSSH Backdoor Vulnerability

3. In 2015 Microsoft issued weird update, see [6],[7].

4. Portable malware in portable languages (Java, Javascript), taking the worst from windoze.

5. Google play. Google play has about 2.8M packages [2] for android. Debian has about 31K packages [3] XXXold_stat. To our surprise google play is only about 90 times bigger than debian per number of packages and the metrics is unclear for size of binary packages or lines of code. Google scans for malware, not sure how effective is this.Google's permissions of applications are mitigating factor.

6. The art of backdooring: sufficiently sophisticated backdoor is indistinguishable from secure code, see Obfuscation contest [4].

7. Getting root vs reading $HOME vs euid == DAEMON. Getting root is important, but there is more interesting in user's $HOME.

1 2 3 4 5 6 7