[scponly] Relative listing outside scponlyc chroot jail allowed?

[Kaleb Pederson]

On Monday 24 September 2007, you wrote:
> So attached comes my second try, this time with "sudo ktrace -i -p PID".

Thanks for the output.  As I'm not very current with Mac's, is "Mac OS X 
10.4.10 (Intel)" the latest fully-patched version?

Can you try with the latest CVS or the snapshot available here:

http://kibab.homeip.net/scponly/snapshots/scponly-20070718.tgz

Given the nature of the problem, I don't expect it to resolve anything, but it 
would help me confirm the issue.

In looking at the trace, it still looks like a kernel bug.  It looks like 
scponly was able to chroot just fine:

(leftmost numbers are the line numbers)
20519   6229 scponlyc CALL  chroot(0x4240)
20520   6229 scponlyc NAMI  "/Users/SomeUser/Sites"
20521   6229 scponlyc RET   chroot 0

It was able to chdir just fine:

20529        "<87>Sep 24 17:37:47 scponly[6229]: chdiring to dir: "/""
20530   6229 scponlyc RET   sendto 55/0x37
20531   6229 scponlyc CALL  chdir(0xbffff850)
20532   6229 scponlyc NAMI  "/"
20533   6229 scponlyc RET   chdir 0

It executes sftp-server fine:

20605        "<86>Sep 24 17:37:47 scponly[6229]: 
running: /usr/libexec/sftp-server (\
20606     username: SomeUser1(1062), IP/port: 213.220.221.246 36346 22)"
20607   6229 scponlyc RET   sendto 132/0x84
20608   6229 scponlyc CALL  execve(0x3005f0,0x300460,0x4a40)
20609   6229 scponlyc NAMI  "/usr/libexec/sftp-server"
20610   6229 scponlyc NAMI  "/usr/lib/dyld"
20611   6229 sftp-server RET   execve 0

Although not critical to anything, it wants /dev/urandom which isn't present 
in the chroot:

20612   6229 sftp-server CALL  open(0x8fe45d8c,0,0xbffffdb8)
20613   6229 sftp-server NAMI  "/dev/urandom"
20614   6229 sftp-server RET   open -1 errno 2 No such file or directory

It finds /dev/null:

21915   6229 sftp-server CALL  open(0x8ef4,0x2,0)
21916   6229 sftp-server NAMI  "/dev/null"
21917   6229 sftp-server RET   open 5
21918   6229 sftp-server CALL  close(0x5)

And here's where it starts to get interesting. [Note: I could use a little 
help deciphering the string encoding that they are doing as I don't have a 
BSD box around here, but I'll probably get around to it sooner/later]:

22196   6229 sftp-server GIO   fd 5 read 14 bytes
22197        "\0\0\0
22198     \v\0\0\0\^D\0\0\0\^A/"
22199   6228 sshd     CALL  select(0xb,0x305ac0,0x305ab0,0,0)
22200   6229 sftp-server RET   read 14/0xe
22201   6229 sftp-server CALL  open(0x300590,0x100004,0x18)
22202   6229 sftp-server NAMI  "/"
22203   6229 sftp-server RET   open 7
22204   6229 sftp-server CALL  fcntl(0x7,0x2,0x1)
22205   6229 sftp-server RET   fcntl 0

Ok, the sftp-server receives a command and in response we open '/' as file 
descriptor 7.  Shortly thereafter, we start reading in files:

22266   6229 sftp-server CALL  getdirentries(0x7,0x1802800,0x1000,0x3005b4)
22267   6229 sftp-server RET   getdirentries 164/0xa4
22268   6229 sftp-server CALL  lstat(0xbffeb8b0,0xbffebcb0)
22269   6229 sftp-server NAMI  "/."
22270   6229 sftp-server RET   lstat 0
...
22305   6229 sftp-server CALL  lstat(0xbffeb8b0,0xbffebcb0)
22306   6229 sftp-server NAMI  "/Streaming"
22307   6229 sftp-server RET   lstat 0
... [ big snip ] ...
23299   6229 sftp-server CALL  lstat(0xbffeb8b0,0xbffebcb0)
23300   6229 sftp-server NAMI  "/..//Movies"
23301   6229 sftp-server RET   lstat 0

The first arg to lstat is a const char*, so it's using the same buffer at 
minimum, although I'm curious what the actual values are.

So... anyway, it's definitely doing things it shouldn't be... and everything 
looks good as far as scponly has behaved.

Jan, is there anyway you can play with kdump so I can see what the strings are 
or so I can decode them a little easier?  If you can't get that to work when 
you run it against the latest CVS, feel free to send me the original actual 
ktrace files in conjunction with whatever dump files you can generate.  I 
will try to get a FreeBSD install setup that I can play with so that I can 
take a better look at the output, etc.

If any of you are BSD experts or have a Mac to test against, I'd appreciate 
any help looking at this.

Thanks.

--Kaleb