Recent changes to bugs

Problem with Security Fix for Windows Version

2007-12-16T06:22:11Z

When attempting to compile with GAPING_SECURITY_HOLE on Microsoft Visual Studio 6.0 I get three errors:

doexec.c
c:\...\cryptcat-nt-1.2.1\nt\doexec.c(438) : error C2065: 'RecvBuffer' : undeclared identifier
c:\...\cryptcat-nt-1.2.1\nt\doexec.c(438) : error C2109: subscript requires array or pointer type
c:\...\cryptcat-nt-1.2.1\nt\doexec.c(438) : error C2109: subscript requires array or pointer type

To fix it, you have to undo the actual "fix" part of it, but if you replace:
<code>
if (RecvBuffer[0] == '\n' || RecvBuffer[0] == '\r' || BufferCnt > BUFFER_SIZE-1) {
</code>
with:
<code>
if (Buffer[BufferCnt - 1] == '\n' || Buffer[BufferCnt - 1] == '\r' || BufferCnt > BUFFER_SIZE-1)
</code>
It will work.

I tried adapting the code to read only one byte at a time, but the farm9crypt_read() function ignored the length of 1 for the size, and read back as much data as it wanted to.

I don't know any cryptography, nor do I understand much of the code in the farm9crypt.cpp file, but could it be adapted to read fewer bytes?

segfault in listen mode

2007-11-25T08:50:13Z

http://bugs.debian.org/431010

cryptcat segfaults in listen mode due to some kind of overflow. A patch is available here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=cryptcat-farm9crypt_read-patch.diff;att=1;bug=431010

Detailed analysis is available here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;att=0;bug=431010

VU#165099 patch

2005-08-10T00:35:31Z

In few words this patch solves VU#165099 Cert
vulnerability for Cryptcat for Unix.

In order to apply apply the patch execute:
tar xfz cyptcat_20031202.tar.gz
gunzip cryptcat.solves_vu165099.diff.gz
cd cryptcat_20031202
patch -p1 < ../cryptcat.solves_cvu165099.diff
make linux

In order to test it execute:
./cryptcat -kwhateverkey -l -p 1234 -e /bin/cat
(from another terminal) ./cryptcat -kwhateverkey
localhost 1234

Tested on Linux.

When original version of crypcat executed a program
with -e option the code that encrypted/decrypted
comunication was destroyed bye exec. So, parent
process must not be destroyed. We have to create a
child process, communicate with parent trough a
bidirectional Unix socket, exec on child so parent lasts
and encryption/decryption code is not destroyed.

I've tried to contact with both Farm9 and Cert and have
no response from them.

More info on my personal web
http://semevalaolla.dyn.ee/~ara/dwn/cryptcat/

cryptcat has an endian problem

2003-11-05T23:25:06Z

Cryptcat compiled on a big-endian architecture like
Sparc will not talk with cryptcat compiled on a
little-endian architecture like Pentium.

The problem is with the macros for extracting specific
bytes from a 4 byte word. The b0(x) macro is supposed
to extract the least significant byte, the b1(x) macro
the next least significant, the b2(x) macro the next
least significant byte and the b3(x) macro the most
significant byte.

These macros are implemented in terms of the _b(x,n)
macro, which extracts the n%4 th byte from x.

Unfortunately, the macros as defined will work
correctly on little-endian machines, but not big-endian
machines.

I have fixed this by defining the _b() and bx() macros
as inline functions which do the right thing with
either endianness. Unfortunately, I had to rename the
bx() macros to bxf() functions because the code uses
regular variables with the same name as the macros(!).
The solution is probably not bulletproof as it assumes
4 byte ints, but my impression is that the whole
program will fall apart if sizeof(int) != sizeof(long)
!= sizeof(char*) != 4 anyway.

After applying this fix, you can cryptcat between
Solaris/Sparc and Linux etc/Intel.

I believe I have a context diff which can be applied to
twofish2.cc and twofish2.h to correct the problem.

OpenBSD compat

2001-06-23T02:55:47Z

on line 2162

2161: HOSTENT *phostent;
2162: int x;
2163: BOOL b;

'int x' => 'unsigned x'

2161: HOSTENT *phostent;
2162: unsigned x;
2163: BOOL b;

in OpenBSD, gethostbyname() (line: 2246) requires the third argument to unsigned.

I dont know how this effects other distro's

Chris Lee
lee@mediawaveonline.com