Gitcurity
-
You can tell it's a Git security issue because the announcement of the fix is as horrible and unreadable as humanly possible.
Anyway Subversion and Mercurial are fixed as well, so update your shiznizz. And remember this next time tells you how secure SSH is.
-
Maybe you should not fork random strangers you find in the corner alleys of GitHub where all gits convene for neferious purposes
-
- In the same spirit, a repository name that begins with a dash "-"
is also forbidden now.
For reasons too embarrassing to disclose, the name of one of my repos actually does start with a dash.
- In the same spirit, a repository name that begins with a dash "-"
-
Makes me wonder if any IDEs and/or IDE plugins for these are also affected.
On a side note, how can you fuck this up, by silently stripping the
ssh://
and then treating that as an argument?
-
@powerlord said in Gitcurity:
Makes me wonder if any IDEs and/or IDE plugins for these are also affected.
Presumably if they support SSH and support "recursing submodules" whatever the fuck that is, they are vulnerable.
-
@blakeyrat A git submodule is just a reference to a specific commit in a different repository on the same git server. "recursive submodules" just means you automatically check out those submodules along with the repository you chose to check out.
(Actually, it probably doesn't have to be on the same git server, but you're asking for trouble in trusting random people on the Internet to not delete their repositories.)
-
@powerlord I didn't ask.
-
For reasons too embarrassing to disclose, the name of one of my repos actually does start with a dash.
-*-~-My-SwEeT-CoDez-xD-~-*-?
-
-
@powerlord said in Gitcurity:
On a side note, how can you fuck this up, by silently stripping the ssh:// and then treating that as an argument?
Even if you parse the string "correctly" and pass it to the command line of
ssh
correctly quoted, the host argument still goes before the double dash (assuming you've added that). Therefore, you can inject a single switch if you're allowed to start your "host name" with a dash.
-
@boomzilla I love that song. Especially when Nelson Muntz sings HAW HAW along with the WOMP WOMP instrumental.
-
This post is deleted!
-
@powerlord said in Gitcurity:
On a side note, how can you fuck this up, by silently stripping the ssh:// and then treating that as an argument?
Even if you parse the string "correctly" and pass it to the command line of
ssh
correctly quoted, the host argument still goes before the double dash (assuming you've added that). Therefore, you can inject a single switch if you're allowed to start your "host name" with a dash.(OK, so I fucked the wording of my last reply up completely, lets try this again).
If your parsing library interprets the
-
in the middle of a string as the start of an option, you should consider dumping it and using a different one.
-
@powerlord said in Gitcurity:
If your parsing library
Haha, nice one. It's probably excecuted as pure bash, no parsing library there. (yes, even on windows it requires bash)
-
@powerlord said in Gitcurity:
If your parsing library interprets the - in the middle of a string as the start of an option, you should consider dumping it and using a different one.
Not sure what you're trying to say here. At some point, your VCS will execute an
ssh
command. And even if you take the usual precautions, an option can be injected via the host name.
-
@powerlord said in Gitcurity:
If your parsing library interprets the - in the middle of a string as the start of an option, you should consider dumping it and using a different one.
Not sure what you're trying to say here. At some point, your VCS will execute an
ssh
command. And even if you take the usual precautions, an option can be injected via the host name.Not if you take precautions. UNIX's getopts, and presumably any clones of it, uses
--
to signify the end of the options list:Any of the following shall identify the end of options: the first "--" argument that is not an option-argument, finding an argument that is not an option-argument and does not begin with a '-', or encountering an error.
-
@powerlord said in Gitcurity:
Not if you take precautions. UNIX's getopts, and presumably any clones of it, uses -- to signify the end of the options list:
Did you read my post above? In case of
ssh
, the double dash goes after the host name and before the (optional) command. So this doesn't help you at all.
-
@asdf I have no idea where you're getting that. The hostname itself is not an option, it's a mandatory part of the command that goes after the options/arguments and before any optional commands you send to the server.
-
@powerlord
Hm, you're right. Putting the double dash before the host name works as well. TIL.I retract my previous statements. git?
-
At some point, your VCS will execute an
ssh
command.Yet another tool suffering from the 'command line is an API' mindworm. Made worse because things you pass in tend to get interpreted by the shell on both sides, making proper escaping a proper nightmare.
-
Yet another tool suffering from the 'command line is an API' mindworm.
If
ssh
wasn't a program whose only purpose is executing remote shell commands, I'd agree with you, but in this case you're wrong.
-
@blakeyrat said in Gitcurity:
the announcement of the fix is as horrible and unreadable as humanly possible
It was pretty clear to me. Much better than Microsoft's announcements: "Somebody could do something bad. Here's a patch".
-
@powerlord said in Gitcurity:
@powerlord said in Gitcurity:
If your parsing library interprets the - in the middle of a string as the start of an option, you should consider dumping it and using a different one.
Not sure what you're trying to say here. At some point, your VCS will execute an
ssh
command. And even if you take the usual precautions, an option can be injected via the host name.Not if you take precautions. UNIX's getopts, and presumably any clones of it, uses
--
to signify the end of the options list:Any of the following shall identify the end of options: the first "--" argument that is not an option-argument, finding an argument that is not an option-argument and does not begin with a '-', or encountering an error.
That's a silly workaround for the bad idea of using the CLI as an API
-
@blakeyrat said in Gitcurity:
@powerlord I didn't ask.
Nobody asked you if you asked. So don't tell us.
-
@powerlord said in Gitcurity:
@powerlord said in Gitcurity:
If your parsing library interprets the - in the middle of a string as the start of an option, you should consider dumping it and using a different one.
Not sure what you're trying to say here. At some point, your VCS will execute an
ssh
command. And even if you take the usual precautions, an option can be injected via the host name.Not if you take precautions. UNIX's getopts, and presumably any clones of it, uses
--
to signify the end of the options list:Any of the following shall identify the end of options: the first "--" argument that is not an option-argument, finding an argument that is not an option-argument and does not begin with a '-', or encountering an error.
Might actually be a GNU feature?
It's particularly necessary for GNU tools as they reorder the argument list. In standard unix,
rm a -rf
will delete filesa
and-rf
. In GNU, it will delete recursively, without confirmation, deletea
, and leave-rf
to be.
-
@another_sam said in Gitcurity:
"Somebody could do something bad. Here's a patch".
Isn't that really all you need to know.
-
@blakeyrat said in Gitcurity:
"Somebody could do something bad. Here's a patch".
Isn't that really all you need to know.
Not if you have to figure out whether you've already been attacked, and whether you have to shut down and patch all systems immediately or not.
-
@blakeyrat said in Gitcurity:
Isn't that really all you need to know.
Not unless you suck the Microsoft dick because you can't handle complex information and decision making.