Sat Jul 24 18:28:55 EEST 2021

Potential symlink attack in python3 __pycache__


Potential symlink attack in python3 __pycache__

Not sure if this is vulnerability, but it looks like
classical symlink attack.

In python3, if a script in directory DIR1 does "import another",
then python3 creates directory __pycache__ in DIR1 and puts
some files in __pycache__.

According to our tests, if DIR1/__pycache__ is symlink to something,
then python3 follows the symlink.

We suspect the attacker has little to no control on the created files,
except that the files are created.

Here is an artificial session of root shooting herself in the leg
on ubuntu 20:

root@bialokote:~# python3 --version
Python 3.8.10
root@bialokote:~# cat /tmp/a.py
try:  import joro2
except:  print("error in import (2)")
root@bialokote:~# cat /tmp/joro2.py
print("in joro 2")
blah=0
root@bialokote:~# rm ~/tests/*
root@bialokote:~# rm /tmp/__pycache__ #XXX
root@bialokote:~# ls -l ~/tests
total 0
root@bialokote:~# ln -s ~/tests/ /tmp/__pycache__ #XXX shooting in leg
root@bialokote:~# python3 /tmp/a.py
in joro 2
root@bialokote:~# ls -l ~/tests
total 4
-rw-r--r-- 1 root root 144 Jul 24 16:58 joro2.cpython-38.pyc
root@bialokote:~#

Posted by chix for free | Permanent link

Thu Jul 22 11:57:32 EEST 2021

ipython3 may execute code from the current working directory


Summary: under certain circumstances, ipython3 may execute
code from the current working directory. This might be a
problem if the current working directory is not trusted.

python3 is safe.

Tested on ubuntu 20.

The following session illustrates it:

joro@bialokote:~/tests/dir2$ pwd
/home/joro/tests/dir2
joro@bialokote:~/tests/dir2$ ipython3 --version
7.13.0
joro@bialokote:~/tests/dir2$ ls ~/tests/dir1
a.py  joro-orig.py  __pycache__
joro@bialokote:~/tests/dir2$ ls ~/tests/dir2
joro.py  __pycache__
joro@bialokote:~/tests/dir2$ cat ~/tests/dir1/a.py
try:  import joro
except:  print("error in import")
joro@bialokote:~/tests/dir2$ cat ~/tests/dir2/joro.py
print("imported joro :)")
joro@bialokote:~/tests/dir2$ ipython3 ~/tests/dir1/a.py
imported joro :)
joro@bialokote:~/tests/dir2$

Posted by joro | Permanent link

Fri Jan 15 11:43:40 EET 2021

Bitcoin trivia

Bitcoin is a cryptocurrency:.

In our humble opinion it is more like crypto gold rather than currency, because it doesn't support fast transactions.

One of its main advantages is that the number of coins has known upper bound, preventing inflation.

In addition it is decentralized, making it "government resistant".

According to [1] it was invented in 2008 by an unknown person or group of people using the name Satoshi Nakamoto and started in 2009.

Its market capitalization is $713,435,159,726 (7.1 * 10^11) and just for comparison the GDP of Bulgaria is 67.93 billion (68 * 10^9) and Tesla's market capitalization is $800 billion (800 * 10^9).

We find it ironic that the anonymous Satoshi Nakamoto is 23rd richest person in the world on January 4, 2021 :)

Unless otherwise stated, all dates apply to sources of Fri 15 Jan 2021.


Posted by money for nothing | Permanent link

Fri Oct 9 14:02:03 EEST 2020

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

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


Posted by sgub | Permanent link

Sat Oct 3 13:47:00 EEST 2020

From the history of Microsoft (part 1)

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:


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


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.


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.


%RIP Windows Phone, we are not crying much.


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.


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$.


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."



Posted by joro | Permanent link

Fri Sep 11 14:04:06 EEST 2020

Text comics 1 (2020-09-11)

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.

Posted by joro | Permanent link

Tue Jul 14 11:16:35 EEST 2020

10x @maniax

Many thanks @maniax for hosting and consulting!

Posted by joro | Permanent link

Mon Jun 1 09:19:29 EEST 2020

Exploitability of the integer overflows in djbdns 1.05?


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

Posted by joro | Permanent link

Thu May 21 12:51:20 EEST 2020

Short notes on qmail security guarantee


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

Posted by djb-ego | Permanent link

Fri Mar 13 13:43:06 EET 2020

Today is the first day of the rest of your life, enjoy it.

Today is the first day of the rest of your life, enjoy it.

Posted by + | Permanent link