Hi All!
ngIRCd 0.8.2, the "hey there are contributors" release has just hit the ground :-) Many thanks go to Florian Westphal for his work!
Everybody running an older version of ngIRCd should upgrade to this version because some remotely exploitable security related bugs (that could cause the daemon to crash) have been fixed!
Note: if you are using the CVS HEAD branch then you should run an CVS update and use the current code base.
Changes since version 0.8.1 are:
- Added doc/SSL.txt to distribution. - Fixed a buffer overflow that could cause the daemon to crash. Bug found by Florian Westphal, westphal@foo.fh-furtwangen.de. - Fixed a possible buffer underrun when reading the MOTD file. Thanks to Florian Westphal, westphal@foo.fh-furtwangen.de. - Fixed detection of IRC lines which are too long to send. Detected by Florian Westphal, westphal@foo.fh-furtwangen.de. - Fixed return values of our own implementation of strlcpy(). The code has been taken from rsync and they fixed it, but we didn't until today :-/ It has only been used when the system didn't implement strlcpy by itself, not on "modern" systems. Florian Westphal, westphal@foo.fh-furtwangen.de.
You can download ngIRCd 0.8.2 (~271 KB) from:
- http://download.berlios.de/ngircd/ngircd-0.8.2.tar.gz - ftp://ftp.berlios.de/pub/ngircd/ngircd-0.8.2.tar.gz - ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/ngircd-0.8.2.tar.gz
And the patch from 0.8.1 to 0.8.2 (~3 KB) as well as GnuPG signatures can be found here:
- ftp://ftp.berlios.de/pub/ngircd/ - ftp://Arthur.Ath.CX/pub/Users/alex/ngircd/
This release has been tagged as "rel-0-8-2" in the CVS.
Regards Alex
Is it safe to double this values in defines.h to allow people to send longer messages? #define READBUFFER_LEN 2048 /* Laenge des Lesepuffers je Verbindung (Bytes) */ #define WRITEBUFFER_LEN 4096 /* Laenge des Schreibpuffers je Verbindung (Bytes) */
#ifdef ZLIB #define ZREADBUFFER_LEN 1024 /* Laenge des Lesepuffers je Verbindung (Bytes) */ #define ZWRITEBUFFER_LEN 4096 /* Laenge des Schreibpuffers fuer Kompression (Bytes) */
Yours Jens
Hi Jens!
Is it safe to double this values in defines.h to allow people to send longer messages? #define READBUFFER_LEN 2048 /* Laenge des Lesepuffers je Verbindung (Bytes) */ #define WRITEBUFFER_LEN 4096 /* Laenge des Schreibpuffers je Verbindung (Bytes) */
#ifdef ZLIB #define ZREADBUFFER_LEN 1024 /* Laenge des Lesepuffers je Verbindung (Bytes) */ #define ZWRITEBUFFER_LEN 4096 /* Laenge des Schreibpuffers fuer Kompression (Bytes) */
No, it's not "safe":
a) The limit of 512 bytes per command ("message") is defined in the RFCs, so you'll most probably break clients (and other servers) as well.
b) Concerning the ngIRCd, you have at least to tweak COMMAND_LEN as well (and possibly other code).
Regards Alex
Alexander Barton alex@barton.de wrote:
Hi Jens! No, it's not "safe":
a) The limit of 512 bytes per command ("message") is defined in the RFCs, so you'll most probably break clients (and other servers) as well.
b) Concerning the ngIRCd, you have at least to tweak COMMAND_LEN as well (and possibly other code).
Is there a way that clients get not kicked when trying to post more than 512 bytes then?
Yours, Jens
-- 'And trust no-- Trust practically no-one. All right? Except trustworthy people.' (Terry Pratchett - Jingo)
Jens Kleine schrieb:
a) The limit of 512 bytes per command ("message") is defined in the RFCs, so you'll most probably break clients (and other servers) as well.
b) Concerning the ngIRCd, you have at least to tweak COMMAND_LEN as well (and possibly other code).
Is there a way that clients get not kicked when trying to post more than 512 bytes then?
Hm, you can try(!) to rise COMMAND_LEN (and the read and write buffers), but I never tested this.
But please note: the client is violating the IRC protocol and definitely broken when it tries to send more than 512 bytes per request to the server. I know that the original ircd is more tolerant here (but unpredictable!), but this is pure luck.
IMO it would make more sense to fix the client than to "break" the server ;-)
Regards Alex
Alexander Barton alex@barton.de wrote:
IMO it would make more sense to fix the client than to "break" the server ;-)
Yeah, but it's not "the" client. The problem are nearly all (different) clients of my users (including mine). Maybe I could change the daemon to just ignore messages that are too long. Am I right that the trouble is caused by the Conn_Close( Idx, NULL, "Request too long", TRUE ); in conn.c line 1255? Instead of closing the connection one could copy only the first 511 bytes.
BTW: The link http://download.berlios.de/ngircd/ngircd-0.8.3.tar.gz under http://arthur.ath.cx/~alex/ngircd/#source is dead.
Yours Jens
Hi Jens Kleine schrieb:
IMO it would make more sense to fix the client than to "break" the server ;-)
Yeah, but it's not "the" client. The problem are nearly all (different) clients of my users (including mine). Maybe I could change the daemon to just ignore messages that are too long. Am I right that the trouble is caused by the Conn_Close( Idx, NULL, "Request too long", TRUE ); in conn.c line 1255? Instead of closing the connection one could copy only the first 511 bytes.
You are right.
But personally I don't think that it is the right way to "only copy (and use) the firts 511 characters" and silently ignore the rest ... but YMMV.
BTW: The link http://download.berlios.de/ngircd/ngircd-0.8.3.tar.gz under http://arthur.ath.cx/~alex/ngircd/#source is dead.
Right, thanks, I know. I still have to upload 0.8.3 to this location but a urgend call of one of our customers came in ...
Regards Alex
Alexander Barton alex@barton.de wrote:
But personally I don't think that it is the right way to "only copy (and use) the firts 511 characters" and silently ignore the rest ... but YMMV.
Well, I prefer it from kicking the person from the server...
Yours Jens
-
Alexander Barton -
Jens Kleine