2014-10-25 14:44:35 +00:00
|
|
|
*.o
|
2015-02-28 07:58:29 +00:00
|
|
|
*.pyc
|
2014-10-25 14:44:35 +00:00
|
|
|
.dirstamp
|
|
|
|
|
.deps
|
2016-03-23 22:16:20 +00:00
|
|
|
.DS_Store
|
2014-10-25 14:44:35 +00:00
|
|
|
/*.pdb
|
|
|
|
|
/*.ilk
|
|
|
|
|
/*.res
|
|
|
|
|
/*.RES
|
|
|
|
|
/*.pch
|
|
|
|
|
/*.rsp
|
|
|
|
|
/*.obj
|
|
|
|
|
/*.exe
|
|
|
|
|
/*.ncb
|
|
|
|
|
/*.plg
|
|
|
|
|
/*.dsw
|
|
|
|
|
/*.opt
|
|
|
|
|
/*.dsp
|
|
|
|
|
/*.tds
|
|
|
|
|
/*.td2
|
|
|
|
|
/*.map
|
2016-04-10 13:26:54 +00:00
|
|
|
/Makefile.mgw
|
2014-10-25 14:44:35 +00:00
|
|
|
/Makefile.vc
|
|
|
|
|
/Makefile.lcc
|
|
|
|
|
/MSVC
|
|
|
|
|
/*.log
|
|
|
|
|
/*.GID
|
|
|
|
|
/local
|
|
|
|
|
/Output
|
|
|
|
|
/pageant
|
|
|
|
|
/plink
|
|
|
|
|
/pscp
|
|
|
|
|
/psftp
|
|
|
|
|
/putty
|
|
|
|
|
/puttytel
|
|
|
|
|
/puttygen
|
|
|
|
|
/pterm
|
2016-03-23 22:22:30 +00:00
|
|
|
/puttyapp
|
|
|
|
|
/ptermapp
|
2020-02-16 12:27:14 +00:00
|
|
|
/psusan
|
2016-03-23 22:13:30 +00:00
|
|
|
/osxlaunch
|
Add an actual SSH server program.
This server is NOT SECURE! If anyone is reading this commit message,
DO NOT DEPLOY IT IN A HOSTILE-FACING ENVIRONMENT! Its purpose is to
speak the server end of everything PuTTY speaks on the client side, so
that I can test that I haven't broken PuTTY when I reorganise its
code, even things like RSA key exchange or chained auth methods which
it's hard to find a server that speaks at all.
(For this reason, it's declared with [UT] in the Recipe file, so that
it falls into the same category as programs like testbn, which won't
be installed by 'make install'.)
Working title is 'Uppity', partly for 'Universal PuTTY Protocol
Interaction Test Yoke', but mostly because it looks quite like the
word 'PuTTY' with part of it reversed. (Apparently 'test yoke' is a
very rarely used term meaning something not altogether unlike 'test
harness', which is a bit of a stretch, but it'll do.)
It doesn't actually _support_ everything I want yet. At the moment,
it's a proof of concept only. But it has most of the machinery
present, and the parts it's missing - such as chained auth methods -
should be easy enough to add because I've built in the required
flexibility, in the form of an AuthPolicy object which can request
them if it wants to. However, the current AuthPolicy object is
entirely trivial, and will let in any user with the password "weasel".
(Another way in which this is not a production-ready server is that it
also has no interaction with the OS's authentication system. In
particular, it will not only let in any user with the same password,
but it won't even change uid - it will open shells and forwardings
under whatever user id you started it up as.)
Currently, the program can only speak the SSH protocol on its standard
I/O channels (using the new FdSocket facility), so if you want it to
listen on a network port, you'll have to run it from some kind of
separate listening program similar to inetd. For my own tests, I'm not
even doing that: I'm just having PuTTY spawn it as a local proxy
process, which also conveniently eliminates the risk of anyone hostile
connecting to it.
The bulk of the actual code reorganisation is already done by previous
commits, so this change is _mostly_ just dropping in a new set of
server-specific source files alongside the client-specific ones I
created recently. The remaining changes in the shared SSH code are
numerous, but all minor:
- a few extra parameters to BPP and PPL constructors (e.g. 'are you
in server mode?'), and pass both sets of SSH-1 protocol flags from
the login to the connection layer
- in server mode, unconditionally send our version string _before_
waiting for the remote one
- a new hook in the SSH-1 BPP to handle enabling compression in
server mode, where the message exchange works the other way round
- new code in the SSH-2 BPP to do _deferred_ compression the other
way round (the non-deferred version is still nicely symmetric)
- in the SSH-2 transport layer, some adjustments to do key derivation
either way round (swapping round the identifying letters in the
various hash preimages, and making sure to list the KEXINITs in the
right order)
- also in the SSH-2 transport layer, an if statement that controls
whether we send SERVICE_REQUEST and wait for SERVICE_ACCEPT, or
vice versa
- new ConnectionLayer methods for opening outgoing channels for X and
agent forwardings
- new functions in portfwd.c to establish listening sockets suitable
for remote-to-local port forwarding (i.e. not under the direction
of a Conf the way it's done on the client side).
2018-10-20 21:09:54 +00:00
|
|
|
/uppity
|
Auxiliary application: 'psocks', a simple SOCKS server.
This is built more or less entirely out of pieces I already had. The
SOCKS server code is provided by the dynamic forwarding code in
portfwd.c. When that accepts a connection request, it wants to talk to
an SSH ConnectionLayer, which is already a trait with interchangeable
implementations - so I just provide one of my own which only supports
the lportfwd_open() method. And that in turn returns an SshChannel
object, with a special trait implementation all of whose methods
just funnel back to an ordinary Socket.
Result: you get a Socket-to-Socket SOCKS implementation with no SSH
anywhere, and even a minimal amount of need to _pretend_ internally to
be an SSH implementation.
Additional features include the ability to log all the traffic in the
form of diagnostics to standard error, or log each direction of each
connection separately to a file, or for anything more general, to log
each direction of each connection through a pipe to a subcommand that
can filter out whatever you think are the interesting parts. Also, you
can spawn a subcommand after the SOCKS server is set up, and terminate
automatically when that subcommand does - e.g. you might use this to
wrap the execution of a single SOCKS-using program.
This is a modernisation of a diagnostic utility I've had kicking
around out-of-tree for a long time. With all of last year's
refactorings, it now becomes feasible to keep it in-tree without
needing huge amounts of scaffolding. Also, this version runs on
Windows, which is more than the old one did. (On Windows I haven't
implemented the subprocess parts, although there's no reason I
_couldn't_.)
As well as diagnostic uses, this may also be useful in some situations
as a thing to forward ports to: PuTTY doesn't currently support
reverse dynamic port forwarding (in which the remote listening port
acts as a SOCKS server), but you could get the same effect by
forwarding a remote port to a local instance of this. (Although, of
course, that's nothing you couldn't achieve using any other SOCKS
server.)
2020-02-23 16:27:04 +00:00
|
|
|
/psocks
|
2016-03-23 22:14:13 +00:00
|
|
|
/unix/PuTTY.app
|
|
|
|
|
/unix/Pterm.app
|
2015-11-08 11:58:27 +00:00
|
|
|
/fuzzterm
|
New test system for mp_int and cryptography.
I've written a new standalone test program which incorporates all of
PuTTY's crypto code, including the mp_int and low-level elliptic curve
layers but also going all the way up to the implementations of the
MAC, hash, cipher, public key and kex abstractions.
The test program itself, 'testcrypt', speaks a simple line-oriented
protocol on standard I/O in which you write the name of a function
call followed by some inputs, and it gives you back a list of outputs
preceded by a line telling you how many there are. Dynamically
allocated objects are assigned string ids in the protocol, and there's
a 'free' function that tells testcrypt when it can dispose of one.
It's possible to speak that protocol by hand, but cumbersome. I've
also provided a Python module that wraps it, by running testcrypt as a
persistent subprocess and gatewaying all the function calls into
things that look reasonably natural to call from Python. The Python
module and testcrypt.c both read a carefully formatted header file
testcrypt.h which contains the name and signature of every exported
function, so it costs minimal effort to expose a given function
through this test API. In a few cases it's necessary to write a
wrapper in testcrypt.c that makes the function look more friendly, but
mostly you don't even need that. (Though that is one of the
motivations between a lot of API cleanups I've done recently!)
I considered doing Python integration in the more obvious way, by
linking parts of the PuTTY code directly into a native-code .so Python
module. I decided against it because this way is more flexible: I can
run the testcrypt program on its own, or compile it in a way that
Python wouldn't play nicely with (I bet compiling just that .so with
Leak Sanitiser wouldn't do what you wanted when Python loaded it!), or
attach a debugger to it. I can even recompile testcrypt for a
different CPU architecture (32- vs 64-bit, or even running it on a
different machine over ssh or under emulation) and still layer the
nice API on top of that via the local Python interpreter. All I need
is a bidirectional data channel.
2019-01-01 19:08:37 +00:00
|
|
|
/testcrypt
|
New test system to detect side channels in crypto code.
All the work I've put in in the last few months to eliminate timing
and cache side channels from PuTTY's mp_int and cipher implementations
has been on a seat-of-the-pants basis: just thinking very hard about
what kinds of language construction I think would be safe to use, and
trying not to absentmindedly leave a conditional branch or a cast to
bool somewhere vital.
Now I've got a test suite! The basic idea is that you run the same
crypto primitive multiple times, with inputs differing only in ways
that are supposed to avoid being leaked by timing or leaving evidence
in the cache; then you instrument the code so that it logs all the
control flow, memory access and a couple of other relevant things in
each of those runs, and finally, compare the logs and expect them to
be identical.
The instrumentation is done using DynamoRIO, which I found to be well
suited to this kind of work: it lets you define custom modifications
of the code in a reasonably low-effort way, and it lets you work at
both the low level of examining single instructions _and_ the higher
level of the function call ABI (so you can give things like malloc
special treatment, not to mention intercepting communications from the
program being instrumented). Build instructions are all in the comment
at the top of testsc.c.
At present, I've found this test to give a 100% pass rate using gcc
-O0 and -O3 (Ubuntu 18.10). With clang, there are a couple of
failures, which I'll fix in the next commit.
2019-02-10 13:09:53 +00:00
|
|
|
/testsc
|
2018-11-27 19:22:15 +00:00
|
|
|
/testzlib
|
2016-03-30 07:25:25 +00:00
|
|
|
/cgtest
|
New utility object, StripCtrlChars.
This is for sanitising output that's going to be sent to a terminal,
if you don't want it to be able to send arbitrary escape sequences and
thereby (for example) move the cursor back up to existing text on the
screen and overprint it confusingly.
It works using the standard C library: we convert to a wide-character
string and back, and then use wctype.h to spot control characters in
the intermediate form. This means its idea of the conversion character
set is locale-based rather than any of our own charset library's fixed
settings - which is what you want if the aim is to protect your local
terminal (which we assume the system locale represents accurately).
This also means that the sanitiser strips things that will _act_ as
control characters when sent to the local terminal, whether or not
they were intended as control characters by a server that might have
had a different character set in mind. Since the main aim is to
protect the local terminal rather than to faithfully replicate the
server's intention, I think that's the right criterion.
It only strips control characters at the charset-independent layer,
like backspace, carriage return and the escape character: wctype.h
classifies those as control characters, but classifies as printing all
of the more Unicode-specific controls like bidirectional overrides.
But that's enough to prevent cursor repositioning, for example.
stripctrl.c comes with a test main() of its own, which I wasn't able
to fold into testcrypt and put in the test suite because of its
dependence on the system locale - it wouldn't be guaranteed to work
the same way on different test systems anyway.
A knock-on build tweak: because you can feed data into this sanitiser
in chunks of arbitrary size, including partial multibyte chars, I had
to use mbrtowc() for the decoding, and that means that in the 'old'
Win32 builds I have to link against the Visual Studio C++ library as
well as the C library, because for some reason that's where mbrtowc
lived in VS2003.
2019-02-20 06:56:40 +00:00
|
|
|
/scctest
|
2014-10-25 14:44:35 +00:00
|
|
|
/*.DSA
|
|
|
|
|
/*.RSA
|
|
|
|
|
/*.cnt
|
|
|
|
|
/*.hlp
|
|
|
|
|
/.bmake
|
|
|
|
|
/build.log
|
|
|
|
|
/build.out
|
|
|
|
|
/uxconfig.h
|
|
|
|
|
/empty.h
|
|
|
|
|
/config.status
|
|
|
|
|
/Makefile.am
|
|
|
|
|
/Makefile.in
|
|
|
|
|
/Makefile
|
|
|
|
|
/compile
|
|
|
|
|
/config.status
|
|
|
|
|
/configure
|
|
|
|
|
/stamp-h1
|
|
|
|
|
/aclocal.m4
|
|
|
|
|
/ar-lib
|
|
|
|
|
/autom4te.cache
|
|
|
|
|
/depcomp
|
|
|
|
|
/install-sh
|
|
|
|
|
/local
|
|
|
|
|
/missing
|
|
|
|
|
/uxconfig.in
|
2019-02-09 14:06:34 +00:00
|
|
|
/uxconfig.in~
|
2014-10-25 14:44:35 +00:00
|
|
|
/uxconfig.h
|
2015-12-22 12:43:31 +00:00
|
|
|
/licence.h
|
2014-10-25 14:44:35 +00:00
|
|
|
/*.a
|
|
|
|
|
/charset/sbcsdat.c
|
|
|
|
|
/contrib/cygtermd/cygtermd.exe
|
|
|
|
|
/doc/*.html
|
|
|
|
|
/doc/*.txt
|
|
|
|
|
/doc/*.cnt
|
|
|
|
|
/doc/*.hlp
|
|
|
|
|
/doc/*.gid
|
|
|
|
|
/doc/*.GID
|
|
|
|
|
/doc/*.chm
|
|
|
|
|
/doc/*.log
|
|
|
|
|
/doc/*.1
|
|
|
|
|
/doc/*.info
|
|
|
|
|
/doc/vstr.but
|
|
|
|
|
/doc/*.hhp
|
|
|
|
|
/doc/*.hhc
|
|
|
|
|
/doc/*.hhk
|
2015-12-22 11:18:48 +00:00
|
|
|
/doc/licence.but
|
2015-12-22 13:56:07 +00:00
|
|
|
/doc/copy.but
|
2016-03-23 06:41:27 +00:00
|
|
|
/icons/*.pam
|
2014-10-25 14:44:35 +00:00
|
|
|
/icons/*.png
|
|
|
|
|
/icons/*.ico
|
2015-09-06 08:50:09 +00:00
|
|
|
/icons/*.icns
|
2014-10-25 14:44:35 +00:00
|
|
|
/icons/*.xpm
|
|
|
|
|
/icons/*.c
|
|
|
|
|
/unix/Makefile.gtk
|
|
|
|
|
/unix/Makefile.ux
|
|
|
|
|
/unix/Makefile.local
|
|
|
|
|
/unix/empty.h
|
|
|
|
|
/unix/plink
|
|
|
|
|
/unix/pterm
|
|
|
|
|
/unix/putty
|
|
|
|
|
/unix/puttytel
|
|
|
|
|
/unix/psftp
|
|
|
|
|
/unix/pscp
|
|
|
|
|
/unix/puttygen
|
|
|
|
|
/unix/stamp-h1
|
|
|
|
|
/unix/*.log
|
|
|
|
|
/unix/.deps
|
|
|
|
|
/windows/*.pdb
|
|
|
|
|
/windows/*.ilk
|
|
|
|
|
/windows/*.res
|
|
|
|
|
/windows/*.RES
|
|
|
|
|
/windows/*.pch
|
|
|
|
|
/windows/*.rsp
|
|
|
|
|
/windows/*.obj
|
|
|
|
|
/windows/*.exe
|
|
|
|
|
/windows/*.ncb
|
|
|
|
|
/windows/*.plg
|
|
|
|
|
/windows/*.dsw
|
|
|
|
|
/windows/*.opt
|
|
|
|
|
/windows/*.dsp
|
|
|
|
|
/windows/*.tds
|
|
|
|
|
/windows/*.td2
|
|
|
|
|
/windows/*.map
|
2019-01-07 19:51:59 +00:00
|
|
|
/windows/*.rcpp
|
2017-02-05 10:59:08 +00:00
|
|
|
/windows/Makefile.clangcl
|
2016-04-10 13:26:54 +00:00
|
|
|
/windows/Makefile.mgw
|
2014-10-25 14:44:35 +00:00
|
|
|
/windows/Makefile.vc
|
|
|
|
|
/windows/Makefile.lcc
|
|
|
|
|
/windows/MSVC
|
|
|
|
|
/windows/DEVCPP
|
|
|
|
|
/windows/VS2010
|
|
|
|
|
/windows/VS2012
|
|
|
|
|
/windows/*.log
|
|
|
|
|
/windows/*.GID
|
|
|
|
|
/windows/local
|
|
|
|
|
/windows/Output
|
|
|
|
|
/windows/*.DSA
|
|
|
|
|
/windows/*.RSA
|
|
|
|
|
/windows/*.cnt
|
|
|
|
|
/windows/*.hlp
|
|
|
|
|
/windows/.bmake
|
|
|
|
|
/windows/*.sln
|
|
|
|
|
/windows/*.suo
|
2016-03-21 19:07:40 +00:00
|
|
|
/windows/*.msi
|
|
|
|
|
/windows/*.wixobj
|
|
|
|
|
/windows/*.wixpdb
|