joushou

Right, and you can do the same with C, using libraries providing this functionality wrapped as well. There's plenty of std::string and std::vector like containers, which handle the magic for you. But even then, you can work with struct {len int; void* data;} to get your vector, and replace void* with char* to get a string. A simple vector and simple string is in no way difficult to implement, and many implementations exist.

I'm just trying to point out that the convenience of some C++ standard library features is not isolated to C++, and C++ is not a "memory safe" language by meaning of the word.

I don't like Java, but don't underestimate the performance of the JVM. Unless you're a crazy perf wiz, then your average C code won't beat your average Java code. It's fast enough for short processes, and for long processes the JIT is pretty darn good. Also note that a JIT can perform runtime assumptions and optimize code based on what is currently the case, which an AOT compiler cannot.

It takes a lot more than a toolchain to write fast code.

As, yeah, stupid applications is hard to guard against, but stupid applications might/will have their own share of code execution bugs, which you also have to control. Everything sucks.

As for the environment, that's the same for any UNIX, though. .bashrc is run only if you start bash. Getting an ubuntu dist. to set up your environment variables in GUI applications certainly won't be fixed with a .bashrc. It might inherit /etc/profile, if you're lucky.

For OS X, launchd handles the environment by simply being the one responsible for starting the applications that you inherit your environment from (such as Finder, Dock and Spotlight), and .bashrc is just a file that bash executes itself that might set additional environment variables. This is not unlike a Linux setup, where you only inherit environment variables written in .bashrc if you started the application from bash.

(OS X does have a path management system for shells in the form of path-helper and /etc/path.d/, but that's run through the profile, which won't affect GUI applications.)

I'm not really trying to defend OS X here, other than pointing out that if you cut out the proprietary GUI stuff, it's basically just your run-of-the-mill custom UNIX dist. As a long time Linux user (I use a Mac as laptop, because screw trying to get Linux working perfectly on a laptop), I find everything to be an equal pain in the ass to deal with. systemd or launchd, X11 or windowserver, Finder, Nautilus, Konqueror or even Windows Explorer - They all suck. Pick your poison.

It doesn't hide anything related to git. The binary in /usr/bin is there to shat xcode-select works and points to /Application/Xcode.app/Contents/.../bin/git. It's not hidden, it's merely a convenience so that you can actually get git, and stay at least a little up to date. There's nothing hidden about it, and installing new, modifying your path, whatever is done just like you would on any other machine.

The binaries are protected by "rootless mode"/System Integrity Protection, but you can disable this and get full root access to your development machine. Just run "csrutil disable" from recovery mode (It wouldn't really help if you could disable it from a running system).

The only locked down things on OS X are proprietary GUI stuff, such as windowserver or some menubar API's. Regular operation is not locked down.

Well, you can, but it's inconvenient and requires manual intervention with each machine. I would argue, though, that if you have developers that intentionally circumvent the version of git you provided them with, despite being told that it's there for security reasons (and is newer, better, flashier and all), then you're dealing with people that can't be helped, and shit will happen regardless.

I'm not arguing that it's okay that Apple bundles an affected version of git, but if they start undoing what you did to protect them, I don't think they can be helped. I'm a bit pessimistic in this sense, but I keep getting surprised by the kind of crap that makes their way onto peoples machines, sometimes people that really should know better.

This is indeed an issue. I would like to think that a person capable of using git would have enough of a critical mindset not to do what random people on the internet tell you to do, but... StackOverflow kinda proves the opposite.

I don't think you'll ever be able to help people that follow internet advice blindly, for these people, it might be better not to bundle anything at all.

> You have the user's execution rights only; you don't have root access.

That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it.

Also, privilege escalation bugs.

> This is true of any program the user runs. The fix is for the user to not run untrusted code. Trusted code should not be modifying .bashrc without the user's knowledge.

Exactly my point. If the .bashrc has been modified in an evil way, as you suggested, you're screwed because someone is executing code as your user, which is usually exactly what they need. Add one privilege escalation, and they can do whatever they want, but that's not really necessary, depending on what they want to do.

In essence, if I can write to a file of my liking on your machine as your user, then I have code execution rights as your user (potentially with a time delay, depending on what I tamper with).

> And the user can unmask them just as easily. It's not at all the same as having root access.

Exactly, like installing a different version of git with homebrew and masking the old one. Also, privilege escalation bugs. I think you're forgetting how common they are. A decent set of privilege escalation bugs is part of any decent hackers toolkit.

If someone modifies .bashrc, as you initially suggested ("Not really, they just need to be able to modify a single file owned by the user (.bashrc), or just the current shell session (again, with a variable owned by the user)"), then the git RCE is redundant, as you already have obtained code execution on the machine.

A little, but you have enough to get started. Rather an old bash than no bash. First task on OS X is usually to use the bundled curl and ruby to get homebrew. :)

No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them.

I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be annoyingly outdated (Like bash 3.2.57, vs. 4.3.42 from homebrew).

With the ability to modify .bashrc, you have execution right to the machine. If not before, to modify the file, then after, because you modified a shell script that is automatically run all the time. Thr machine is already pwned, and one privilege escalation bug away from being completely lost.

With this level of privileges, you can, on any machine, mask existing binaries with whatever you want. It is hardly related to the issue with git.

I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH. Tricking you into using the old version would require execution rights on the machine. You can also remove the /usr/bin/* binaries if you boot the machine without the system integrity features. You can boot back to normal after the modification.

It is inconvenient that these dev tools are not updated frequently (bash, zsh, and many other command line tools are terribly out of date), but it is not terribly difficult to install a fresh version in parallel.

You're talking about naked char[]. You can just as easily make a struct{ int len; char* str; } in C, and combined with the "n" variants of string operations, would work just fine with common tools.

Again, C++ does not make anything safer, and its types can easily be replicated in any other language.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

You're not alone in your concerns. Dynamically generating static layouts seem rather silly to me.

If you tied the local FW magic to a socks5 client, you'd be able to skip part of the magic, assuming you don't desperately need mDNS. SOCKS5 does UDP too, IIRC. I like tearing things apart, and I like making clean muggler solutions, rather than relying on wizardry. :)

With that said, I might still end up using sshuttle as it is. It's a nice project. I just crave for tinkering around. :D

It's also good to know that you completely ignored security advice from security professionals, making this a waste of time. You could say that up front as well: "I'm going to write a comment insulting you, but don't you DARE try to disprove me with logic!"

Statically linked, but you can replace the entire application. You'd get one or two private key signa before the user disconnects and starts wondering what happened (remember that you need to have something to sign).

Of course, without askpass, a properly patched evil sshmuxd could sign a separate session while still signing ths original.

As I have said many times, ssh -W ProxyCommand makes you immune to evil jump hosts, but if root on a machine in your network got compromised, as would be required, then you're going to have a bad day regardless.

ssh -D (socks5 mode) doesn't require root, and can forward both udp and tcp traffic, doing what it appears that the client requires. socks5 is just a protocol that tells the server to connect to X on port Y using protocol Z, or to bind to X on port Y using protocol Z. Root is only required if you want to bind to privileged ports. A bonus with this is that it only requires a SSH server in default configuration.

SOCKS5 most common usage is to just use it as a proxy for HTTP traffic or similar, but it can make any connection. The trick lies in the "kludgy tunnelling operations" and the "router" (firewall rules).It's this magic that makes it better than the socks5 proxy solution, as it really does appear like a VPN. I wonder how much effort it would be to get rid of some of the "magic", though.

But I have to agree, that ANYTHING is better than a real VPN in complexity.

sshmux is a jump host that allows more user-control than you can with a ssh server. Unless you use the interactive mode with agent forward, you still need to configure your client to use one.

I'm not sure I get what you're on about, to be honest. :/

I have to disagree with you.

1. The private key is not secure by default by putting it on a different host. 2. This still allows an evil user getting access to his original machine to SSH into any host requiring his private key.

1 should be pretty obvious. If my intention is to get a hold of the actual private key file, he just moved the target. As for 2: We're talking about avoiding compromising a private key file stored on the client, so in order for that to be an issue in the first place, we're giving an evil user Y reading abilities on the local client. The normal user is called user X. The evil thing to do is to log into the other server on poor user X's behalf. User X used SSHProxy, and moved his private key to a raspberry pi. So, what does evil user Y do on user X's computer?

He just logs in through the SSHProxy, getting access to the remote service. Having the raspberry pi disconnect at times doesn't really matter, as that just means patience (or starting a job that keeps trying). Once logged in, evil user Y could add another key to the authorized_keys file if he wanted to.

Having a service automatically sign things with private key A stored in remote location B, as long as you provide private key B stored in "easily accessible" location A (Which we still assume due to thinking the private key was insecure) is no more secure than storing private key A in "easily accessible" location A. The only argument becomes the ability to occasionally take the pi offline, which doesn't seem to be what he touts as a reason for the project. The issue with this is essentially a reversed modified version of the ssh-agent socket issue, which is blindly signing things as well.

If you truly want to protect your private key: * Encrypt a USB dongle * Put a password protected private key on it * Only plug said USB dongle in when you need it, store separately from your laptop (on your person) * Change your password occasionally

Likewise, having a TPM be your signer doesn't change anything if you have it sign blindly. PCR's allow you to at least verify system state first, but using the TPM in this case only protects you against people stealing your filesystem without your physical machine. With access to the machine, the TPM will keep on signing things blindly. User interaction beats TPM in all areas. One of the cute features TPM was supposed to bring, that actually was going to matter (if you ask the manufacturers, that is) was Remote Attestation. Unfortunately, it wasn't any good and was never used for anything.

Also, for future reference, while it's completely okay to suggest that people are wrong or misunderstanding, there are nicer ways to say it than "You are just wrong", and "not understanding something when they criticise it". I have no idea about your qualifications, and you have no idea about mine. We're all humans, so be polite about it. No one likes being insulted.

> sshmux looks like an interesting project, and love the simplicity. Wonder if Userify might automate the ProxyCommand setup! Seems really useful.

Yeah, ProxyCommand is a bit cumbersome for many setups, which is why the agent forwarding mode has the interactive selection screen...

If you feel like poking at sshmux or think there's anything that would be helpful if added, don't hesitate to add it to the issue tracker. Real-life use-cases get higher priority.

> Thanks! We have 350 companies on the platform right now and growing fast, and Userify Enterprise (on-premise) is in beta at several large enterprises as well.

That's great! I guess getting Userify Enterprise out of beta is a bit thing on the roadmap.

> BTW, joushou, we're looking for brilliant SSH and golang hackers.. ping me if you get bored :)

It sounds very interesting (I like Go and SSH, what can possibly go wrong?!), and I am indeed occasionally bored, but I'm ~8000km away... Commuting from Sweden to Denmark is bad enough! ;)

When I use SSH as VPN, it's usually because I want less flexible applications to use it, using socks5 configured as a system-level proxy. When doing more work on our corporate network, I usually SSH through the jump to my desktop and work from there, unless I specifically need to access another machine for something.

As for sshuttle, it's a very convenient device, although the design appears rather complicated. I'll look into it.

I see why you might think that, but no. SSHProxy tries to move the private key from your computer to an external thing. SSHProxy doesn't have anything to do with sshmux.

SSHProxy is a two part thing:

1. A server that, when connected to, will ssh to the requested host, but authenticate with a local private key.

2. A client that will, when connected to the server, work like netcat for ProxyCommand purposes.

I'm skipping some info about additional SSH sessions being involved, as they don't provide any additional security.

The result is essentially ProxyCommand="ssh -W %h:%p jump_host", but instead of you having the private key, the jump_host has it. You then use a different private key to authenticate to the jump host.

I get the idea, and I by no means say he shouldn't have implemented it, but this provides no additional security what so ever. It just moves your private key from one machine to another. I hope he had fun implementing it, though! If you don't implement what might be a bad idea, you'll never get around to the good ones. Plus, bad ideas can be fun, even if they remain bad when done.

What authentication do you have from the jump host to the target? To me, it looks like it has been reduced to either none or keyboard-interactive (password) login, which is considered bad practice. I could very easily implement support for this in sshmux, providing the setup you seem to use, as a way to avoid agent forwarding, but I just genuinely did not expect anyone to use password authentication, apart from in default config scenarios, before a public key has been installed.

Agent forwarding does not provide private keys, but only individual signing requests. This means that while the user is connected, and evil remote can request arbitrary signing, but only as long as the user is connected, and only as long as the users ssh agent is willing to do so. Using ssh-add -c further means that the user will have to accept each signing request. Also note that ssh -W, which is immune to any of these concerns, is fully supported by sshmux.

Correct me if I'm wrong, but "Jailkit" does not seem to stop an evil legitimate user from poking around other hosts with forwarding and such (which they can as long as ssh -W functions, within the limits of what a firewall allows the jump host to do in general). sshmux allows you to lock users to targets, rather than lock general capabilities of the entire jump host. This is because, while I provide clients access to various hosts, I do not trust them enough to have any unnecessary privileges.

Hi CTO for Userify person!

One thing is setup of jump hosts (basic version just being a box with sshd enabled + users with authorized_keys, which is beyond simple), but it's the limitation of hosts. I have 1 big network where a set of users are only allowed to jump to 1 or more unique host each, with myself and a few others being able to jump to every single one. I believe that your solution requires things to be on different subnets to isolate them, with separate jump hosts for each subnet, correct? Here, I only need one sshmux for everyone.

Another "fun" feature is that sshmux can also throw unknown users to a separate host, such as ssh-chat, for support or hanging out.

Actually, in case of -oProxyCommand="ssh -W %h:%p jump_host", you're still fully secure in the case that the jump host (sorry for not calling it a jumpbox) is compromised. This is true both for normal SSH servers and for sshmux. They can mess with the original raw ssh connection that requests the forward, but this will just screw the connection up. They can connect it to a wrong host, but that will provide incorrect host keys. The agent isn't forwarded, so they don't get to sign anything with the private key. Messing with the new connection that gets established is subject to SSH's normal MITM resistance. This means that even root on the jump host would require real SSH protocol vulnerabilities to attack the connection.

Good luck with Userify!

You need arbitrary read and write memory access to abuse it (how would you otherwise make the signing request? You can't just steal one, as they're unique for their purpose), not just read, which is much more than heartbleed was capable of. You of course have this with root, but I'd like to point it out regardless.

I wrote it because, in the case that you have an evil user that scans all physical memory, you can't do anything on the computer and still be safe. ssh -W bypasses the host, and due to various cryptographic features of that setup, the only thing that could happen would be to have someone break the connection or present you with incorrect host keys, which the client would detect. I'm of course assuming that they don't have a SSH vulnerability, as that's a completely different story regardless of agent forwarding.

You can't use that machine for anything else and still be safe, and the presence of that machine on your network is a bad sign, most likely indicating that other things will be taken over as well in the same way that they got first one, or already is compromised, including some of your endpoints. While agent forwarding to the final host isn't necessary, your network is compromised, meaning that other important thing most likely got stolen, just not your private key. If your trumph card is that they don't have your private key, it's kind of like standing at a house that has been completely destroyed with all valuables in it, holding a key and saying "Well, at least they didn't get the key for the front door!". In this case, having private keys for different purposes would be a good way to isolate things, just in case. I personally separate work keys and private (as in spare time) keys.

I know I'm exaggerating the comparison a bit, but the setup required to take over agent forwarding on a network you control, means that you're screwed regardless. Agent forwarding should be used with care, ssh-add -c being absolutely necessary, but agent forwarding has its uses, and many of the cases where I'd be attacked means that I have more pressing matters to deal with.

Landskrona, actually. Malmö would have been nicer, but the waiting list for an apartment is 2-3 years.

It's actually quite common, especially in Malmö (Malmö<->Copenhagen takes about half an hour, Landskrona<->Copenhagen 1:20), for a lot of reasons. The first being that living expenses, including rent and household items, are cheaper in Sweden. Local wages are always adjusted after the local living expenses, so living in Sweden while working in Denmark is economically favorable, especially seeing that you get a tax deduction bonus based on distance from home to work through the shortest feasible route. Cars are also orders of magnitude cheaper in Sweden due to different taxing. Not everything is cheaper or better there, though. Diesel and alcohol is more expensive, and my selection of rye bread is much narrower up there!

For me, it's due to me wanting to start a life with my wife, and a lot private things going on that made Sweden the obvious choice.

Oooooooh, I missed that one. It would have been better if it wasn't an option, but default behaviour, but I guess we can't win every time...

VPN's can be quite a pain, and is considerably more work than raw SSH. Depending on the VPN, the authentication strength is usually also quite a bit lower than that of SSH with RSA keys. There's also additional overhead. I have both VPN and jump hosts to get into our corporate network, and I most certainly prefer the jump host for convenience and performance.

There is also the user-level access restrictions of sshmux which will be much more difficult to replicate with VPN's. At least with pptpd, I believe it would require putting users on individual subnets with firewall rules restricting access to only their permitted hosts. Long story short, it wouldn't be a feasible solution.

+1, although a bit more information would be nice ("Use key for session XYZ").

I'm curious, how did you get that set up?