Re: Troff dangerous.

From: Aaron Campbell (aaronat_private)
Date: Mon Jul 26 1999 - 20:45:30 PDT

  • Next message: David Luyer: "Re: (How) Does AntiSniff do what is claimed?"

    On Mon, 26 Jul 1999, Nic Bellamy wrote:
    
    > I've also checked OpenBSD 2.5 and FreeBSD 3.2 - the groff on both systems
    > defaults to the unsafe behaviour.
    
    OpenBSD-current has been fixed to pass the -S (safer mode) option to groff
    from the nroff.sh script. Please see the following URL:
    
    http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/groff/nroff/nroff.sh
    
    Since all pre-formatted man pages are assembled from nroff and man(1) itself
    uses nroff to compile manuals on-the-fly, this seems to be a reasonable fix.
    
    Again, this (mis)feature has been known for years (the opena/write/pos macros
    are clearly documented, in fact!) Not really any different than installing and
    running software from untrusted sources, but a good heads up and -S is
    definitely a good idea as an extra precaution.
    
    I wasn't going to start a whole new thread about it, but since I'm writing
    this I might as well mention it. FreeBSD PR/6317 notes a problem in the
    telnet(1) client. The -E option disables escape characters entirely so it is
    not supposed to be possible to escape to the `telnet>' prompt. However, if the
    -8 (binary) option is specified to telnet as well (i.e., telnet -8E <host>),
    sending a 0xFF character would indeed still cause the escape.
    
    This could be a security issue on systems that jail users in "canned"
    environments (i.e., lynx-only freenet systems) but allow use of the telnet
    client. If the bug described above were present and the conditions were right,
    a user may be able to escape to the telnet> prompt and, for example, run shell
    commands using the `!' mechanism.
    
    FreeBSD fixed this and OpenBSD adopted the fix as well. I have no idea about
    the status of other operating systems. Oh, Andrew Maltsev <amat_private> filed
    this problem report. If you want to test this on your system, it can be easily
    done in X. Open up an xterm and type: printf "\777\n" at the shell prompt.
    Highlight and copy the strange character printed. Now do a telnet -8E <host>
    and paste the character, see if it escapes to the prompt. Ok, this might not
    work on all systems, but it worked for me.
    
    Since we were on the subject of a fairly *cough* minor *cough* security issue
    I thought I'd bring this up.
    
      .
     :  Aaron Campbell <aaronat_private> - [ http://www.biodome.org/~fx ]
      `-------------------------------------------------------------------
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:53:51 PDT