1516360...@qq.com
Dear telnet team:
I am having some problems with the telnet feature:
1. The telnet login page is displayed slowly, taking 20 seconds. But this
print, "someone wants telnet accept, ctrl 3 + Closing from 4," comes out very
quickly.
2. In 2.3 and 2.4 source
; > > someone has described a remote DoS vulnerability in
>> > > many telnetd implementations that I just happened to
>> > > stumble over:
>> > >
>> > > https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-
lity in
> > > many telnetd implementations that I just happened to
> > > stumble over:
> > >
> > > https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-inetutils-telnetd-kerberos-telnetd.html
> > >
> > > T
I do not expect to find time before the weekend.
> Do you see any way to check for regressions that doesn't involve running
> telnetd/telnet on the command line? I'm thinking a automake C check
> that links to relevant internals.
No idea. I have not really looked at the cod
Hi!
On Sun, 2022-08-28 at 14:40:44 +0200, Erik Auerswald wrote:
> On Sat, Aug 27, 2022 at 07:37:15PM +0200, Erik Auerswald wrote:
> > someone has described a remote DoS vulnerability in
> > many telnetd implementations that I just happened to
> > stumble over:
> >
>
he
> crash by preventing the NULL pointer dereference.
Thanks -- looks good to me, would you like to commit it? Please add a
suitable NEWS entry.
Do you see any way to check for regressions that doesn't involve running
telnetd/telnet on the command line? I'm thinking a automake C check
that links to
Hi all,
On Sat, Aug 27, 2022 at 07:37:15PM +0200, Erik Auerswald wrote:
>
> someone has described a remote DoS vulnerability in
> many telnetd implementations that I just happened to
> stumble over:
>
> https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-teln
Hi all,
someone has described a remote DoS vulnerability in
many telnetd implementations that I just happened to
stumble over:
https://pierrekim.github.io/blog/2022-08-24-2-byte-dos-freebsd-netbsd-telnetd-netkit-telnetd-inetutils-telnetd-kerberos-telnetd.html
The vulnerability is a NULL
If anyone here is interested, here's a patch for building telnet/telnetd
against Heimdal Kerberos 5.
You might have to add LIBS='-lcom_err' to your make invocation since the
krb5-config script provided by Heimdal doesn't do it.
You'll also have to do the following configuration changes
On Sat, 2020-04-11 at 13:03:34 -0400, Alfred M. Szmidt wrote:
>> Thank you for your bug report, please specify which inetutils versions
>> you are refering to in pristine condition without any patches. You
>> mention an assert, which assert exactly?
>
>The inetutils version in
> Thank you for your bug report, please specify which inetutils versions
> you are refering to in pristine condition without any patches. You
> mention an assert, which assert exactly?
The inetutils version in Debian is based off upstream's 1.9.4 with
30 patches from upstream git
> I've been notified of a security vulnerability in inetutils telnetd,
> > which was reported initially against netkit-telnet, but that one has
> > been fixed in Debian for a very long time (around two decades ago [N]).
> Thank you for your bug report, please specify which
I've been notified of a security vulnerability in inetutils telnetd,
which was reported initially against netkit-telnet, but that one has
been fixed in Debian for a very long time (around two decades ago [N]).
Thank you for your bug report, please specify which inetutils versions
you
Hi!
I've been notified of a security vulnerability in inetutils telnetd,
which was reported initially against netkit-telnet, but that one has
been fixed in Debian for a very long time (around two decades ago [N]).
But the code inherited from the BSDs seems to still be around in
inetutils. I've
---
telnetd/utility.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/telnetd/utility.c b/telnetd/utility.c
index 42f624e7..fe40e3b5 100644
--- a/telnetd/utility.c
+++ b/telnetd/utility.c
@@ -63,7 +63,7 @@ static int ncc;
static char ptyibuf[BUFSIZ], *ptyip;
static int pcc
Tisdag den 11:e juli 2017, klockan 14:45, skrev Chris Severance detta:
> Try compiling with -fstack-protector-strong. If that's not enough you'll
> need to add -fstack-protector-strong to your glibc. The easiest way to
> do that is to install an Arch based distro and install inetutils-git
> from
Try compiling with -fstack-protector-strong. If that's not enough you'll
need to add -fstack-protector-strong to your glibc. The easiest way to
do that is to install an Arch based distro and install inetutils-git
from the AUR with the patch removed.
The right way to fix this is to not repeat the same gibberish code 7
times, and then having a sensible test that checks the output. Which
is exactly why I asked a means to reproduce the problem. That is not
at all provided by the original bug report!
r the
report! Here's a patch fixing the issue, which was obvious by just
looking at the code indicated by the warning.
Thanks,
Guillem
From c4f1bc8e2e9e6303a33e1babfffafef9aa628c49 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guil...@hadrons.org>
Date: Tue, 11 Jul 2017 12:22:41 +0200
Subjec
There's nothing to reproduce.
Clearly there is, since I cannot reproduce it. Please don't let us
guess what you are doing, it is not productive.
_s), __fmt, __va_arg_pack ());
~
Unfortunately gcc 7.1.1 -stack-protector is also bugged and can't always
detect this.
On Mon, Jul 10, 2017, at 04:34 PM, Alfred M. Szmidt wrote:
>2017-02-21 18:50 Mats Erik Andersson o telnetd: Debugging of line mode
2017-02-21 18:50 Mats Erik Andersson o telnetd: Debugging of line mode
options.
9db2d39777f8d37496265fc732e640a2ea0c9a29
This new code is causing a buffer overflow. I can immediately see that
char data[6] doesn't include space for the trailing \0. I tried boosting
to "
https://aur.archlinux.org/packages/inetutils-git/
2017-02-21 18:50 Mats Erik Andersson o telnetd: Debugging of line mode
options.
9db2d39777f8d37496265fc732e640a2ea0c9a29
This new code is causing a buffer overflow. I can immediately see that
char data[6] doesn't include space for the trailing
https://aur.archlinux.org/packages/inetutils-git/
2017-02-21 18:50 Mats Erik Andersson o telnetd: Debugging of line mode
options.
9db2d39777f8d37496265fc732e640a2ea0c9a29
This new code is causing a buffer overflow. I can immediately see that
char data[6] doesn't include space for the trailing
hi all,
On Fri, Apr 29, 2016 at 11:49:38AM +0200, Michael Brunnbauer wrote:
> On Fri, Apr 29, 2016 at 04:46:58AM -0400, Alfred M. Szmidt wrote:
> > inetd[24051]: cannot execute /usr/libexec/telnetd: Bad address
> >
> > [...]
> >
> >Is this a bug in te
Hello Alfred,
On Fri, Apr 29, 2016 at 04:46:58AM -0400, Alfred M. Szmidt wrote:
> inetd[24051]: cannot execute /usr/libexec/telnetd: Bad address
>
> [...]
>
>Is this a bug in telnetd?
>
> Possibly, can you attach gdb to telnetd and see what happens?
Sorry b
inetd[24051]: cannot execute /usr/libexec/telnetd: Bad address
[...]
Is this a bug in telnetd?
Possibly, can you attach gdb to telnetd and see what happens? Do you
know if it works with a older version of inetutils? Can you execute
the telnetd binary directly?
I am guessing
hi all,
I recently upgraded a Linux system of a customer (Kernel 3.4.111) to
glibc-2.23, which caused inetd + telnetd from inetutils-1.9.1 to break:
inetd[24051]: cannot execute /usr/libexec/telnetd: Bad address
The inetd.conf entry for this is:
telnet stream tcp4nowait root/usr
On Sat, Aug 15, 2015, at 05:22 PM, Mats Erik Andersson wrote:
On the other hand, with the reversion you suggest and support,
the same server binary running on an OpenIndiana system is not
able to detach the connection after an 'exit' issued by the
client, two [sic] further carrage returns are
Thank you for your detailed explanations.
I understood why your patch works without problem.
Best regards,
Takashi Yano
On Sun, 22 Mar 2015 10:37:37 +0100
Mats Erik Andersson mats.anders...@gisladisker.se wrote:
Dear Takashi Yano!
Den 22 March 2015 klockan 14:32 skrev Takashi Yano detta:
Dear Takashi Yano!
Den 22 March 2015 klockan 14:32 skrev Takashi Yano detta:
Thank you for your reply.
With your patch, I have confirmed the problem has disappeared.
However, I am a little bit concerned about calling pty_get_char(0)
twice in the case of TIOCPKT_FLUSHWRITE or
Saturday den 28 February 2015 klockan 14:15 skrev Takashi Yano detta:
Package: inetutils
Version: 1.9.2 or older
Telnetd in inetutils package lacks handling of some of TIOCPKT
control bytes. The most influential thing is a lack of handling
of TIOCPKT_DATA. TIOCPKT_DATAs i.e. '\0's
Andersson mats.anders...@gisladisker.se wrote:
Saturday den 28 February 2015 klockan 14:15 skrev Takashi Yano detta:
Package: inetutils
Version: 1.9.2 or older
Telnetd in inetutils package lacks handling of some of TIOCPKT
control bytes. The most influential thing is a lack of handling
Package: inetutils
Version: 1.9.2 or older
Telnetd in inetutils package lacks handling of some of TIOCPKT
control bytes. The most influential thing is a lack of handling
of TIOCPKT_DATA. TIOCPKT_DATAs i.e. '\0's frequently appear in
the stream of network side. TIOCPKT_FLUSHREAD, TIOCPKT_STOP
Hi,
I am using telnetd, there I am seeing fcnt64(/var/run/utmp is failing )
which internally causing delay in login to the machine..
I have checked the file utmp file, but this file is fine.
can you please help me to check this issue further?
Regards,
Hemantha
/bin/telnetd --version
telnetd
Petr Malát o...@malat.biz writes:
I have a customer using this patch and he will probably complain in
the case the patch is causing problems. So it is tested, somehow :-)
Thanks, I have applied the patch now.
/Simon
Petr Malát p...@malat.biz writes:
Hi,
I found a problem in terminaltypeok() function, which calls tgetent()
with 1kB buffer. This is fine, if telnetd is linked against ncurses,
but if it is linked against GNU termcap, there is a buffer overflow
for xterm (and maybe other) terminal type
I have a customer using this patch and he will probably complain in
the case the patch is causing problems. So it is tested, somehow :-)
BR,
Petr
2012/8/22 Simon Josefsson si...@josefsson.org:
Petr Malát o...@malat.biz writes:
Hello again,
I found a problem in telnet demon in a function,
Hi,
I found a problem in terminaltypeok() function, which calls tgetent()
with 1kB buffer. This is fine, if telnetd is linked against ncurses,
but if it is linked against GNU termcap, there is a buffer overflow
for xterm (and maybe other) terminal type, which requires 2030 bytes
and telnetd
should apply it.
/Simon
PS: I'm not subscribed to the mailing list, please respond also on my address.
--- inetutils-1.9.1/telnetd/utility.c 2012-08-22 12:24:32.0 +0200
+++ inetutils-1.9.1/telnetd/utility.c 2012-08-22 12:46:56.642636000 +0200
@@ -402,19 +402,23 @@ pty_read (void)
void
#
telnet stream tcp6 nowait root \
/usr/local/sbin/telnetd -h -a user -S telnet/localhost@LOCALHOST
* User setup:
user@localhost $ echo 'user/admin@LOCALHOST' ~/.k5login
$ chmod 0600 ~/.k5login
* Invokation steps:
$ shishi user/admin@LOCALHOST
these enhancements:
* Server setup:
## /etc/inetd.d/telnet
#
telnet stream tcp6 nowait root \
/usr/local/sbin/telnetd -h -a user -S telnet/localhost@LOCALHOST
* User setup:
user@localhost $ echo 'user/admin@LOCALHOST' ~/.k5login
$ chmod 0600
Simon Josefsson si...@josefsson.org writes:
However from there on it stalls. Sometimes it disconnected. The syslog
on the server has plenty of these:
I got it to work! I forgot to 'adduser --disabled-password user' on the
server. Below is a transcript of a kerberized telnet login using
!] there was a segmentation fault
when krb5shishi_status() issued shishi_authorized_p(), caused
by the invalidation of the handle. This is how I discovered
the matter. Not easy to back track after that, though.
Yeah, these function pointer structs are a bit messy.
The issue at hand originates in telnetd
This should be reported by the Debian/Guilliem to gnulib. Guilliem,
please report this to the gnulib maintainers.
I did a test run in GNU/kFreeBSD and came only as far
as a compile failure of telnetd/telnetd.o:
make: Entering directory `/tmp/inetutils/telnetd'
CC
Hi!
On Tue, 2010-11-02 at 23:53:06 +0100, Mats Erik Andersson wrote:
I did a test run in GNU/kFreeBSD and came only as far
as a compile failure of telnetd/telnetd.o:
make: Entering directory `/tmp/inetutils/telnetd'
CC telnetd.o
In file included from telnetd.h:47
I did a test run in GNU/kFreeBSD and came only as far
as a compile failure of telnetd/telnetd.o:
make: Entering directory `/tmp/inetutils/telnetd'
CC telnetd.o
In file included from telnetd.h:47,
from telnetd.c:23:
/usr/include/stropts.h:67: error
I did a test run in GNU/kFreeBSD and came only as far
as a compile failure of telnetd/telnetd.o:
make: Entering directory `/tmp/inetutils/telnetd'
CC telnetd.o
In file included from telnetd.h:47,
from telnetd.c:23:
/usr/include
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Hello there,
the functionality problem of telnetd in OpenBSD, which I mentioned
recently in another letter, has an elementary solution.
For the record, without this minute change telnetd fails on every
connection under OpenBSD
onsdag den 27 oktober 2010 klockan 00:46 skrev Simon Josefsson detta:
Mats Erik Andersson mats.anders...@gisladisker.se writes:
For the record, without this minute change telnetd fails on every
connection under OpenBSD, be it IPv4 or IPv6.
Your patch looks correct to me, so I pushed it. I
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Hello,
three straighforward patches to
man/Makefile.am: Use $(MAKE)
telnetd/telnetd.c: Use PATH_LOGIN
I have applied these two, thanks.
ifconfig/if_index.c: Encapsulate using HAVE_STRUCT_IF_NAMEINDEX
Here I am less
tisdag den 21 september 2010 klockan 10:56 skrev Simon Josefsson detta:
Mats Erik Andersson mats.anders...@gisladisker.se writes:
ifconfig/if_index.c: Encapsulate using HAVE_STRUCT_IF_NAMEINDEX
Here I am less certain, so I didn't push this one. All these #ifdef's
are ugly. Can't we
tisdag den 21 september 2010 klockan 12:32 skrev Simon Josefsson detta:
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Without the proposed change, OpenBSD comes to a halt with a cryptic
message about clashing prototypes for free(3). The explanation is
that OpenBSD uses
Mats Erik Andersson mats.anders...@gisladisker.se writes:
tisdag den 21 september 2010 klockan 12:32 skrev Simon Josefsson detta:
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Without the proposed change, OpenBSD comes to a halt with a cryptic
message about clashing prototypes
Simon, you might want to push this. :-)
PS. Two spaces after end-of-sentence period.
Alfred M. Szmidt a...@gnu.org writes:
Simon, you might want to push this. :-)
Oops!
PS. Two spaces after end-of-sentence period.
Fixed as well.
Thanks,
Simon
Mats Erik Andersson mats.anders...@gisladisker.se writes:
Hello,
the Texinfo page for Telnetd is seriously lacking essential
information. Let me propose the following additions. They
have been compiled from the source 'telnetd/telnetd.c'.
Hi. Thanks for the patch. I installed it after
Hello,
the Texinfo page for Telnetd is seriously lacking essential
information. Let me propose the following additions. They
have been compiled from the source 'telnetd/telnetd.c'.
The little experience I have in writing Texinfo source,
only lead me to use '@samp{}' repeatedly to accomplish
Handling of the TIOCPKT byte seems broken in telnetd.
TIOCPKT_DATA and several control status flags are
not caught. They pass straight through and show up in
the log file when a telnet session is logged.
With bash you could try this and check the log:
telnet localhost 21 | tee log.txt
(The NULL
59 matches
Mail list logo
