Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
char name[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
--
dg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
char name[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
--
dg
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 04:10:27PM -0500, Steve Greenland wrote:
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
11.12a: What's the correct declaration of main()?
A: Either int main(), int main(void), or int main(int argc,
char *argv[]) (with alternate spellings of argc and *argv[]
obviously allowed). See also questions 11.12b to 11.15 below.
References: ISO Sec. 5.1.2.2.1, Sec. G.5.1; HS Sec. 20.1 p.
416; CTP Sec. 3.10 pp. 50-51.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
Exactly because it's definition int main() is correct too, but spelling it
as int main(void) is better style IMHO.
I think I may ask about this on comp.std.c.
Oh no, not again! :)
[snip]
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
Or socket, or whatever.
BTW, fgets will have non-NULL return value if that happens. Unfortunately
fgets won't report number of characters read. So it's better resort to
reading one character at time with fgetc if it's important to know how much
data we got.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Ah, now try to convince people to submit their code for review. :)
Unfortunately many people take comments on their coding style as personal
offense :(
--
dg
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 11:34:28PM +0200, Tim van Erven wrote: [snip] Possible access to unallocated memory if \0\n supplied as input. Only if strlen(name) = 0 and besides from being hard to achieve when entering data on stdin, fgets will return 0 if that happens. But not if you feed it a file. I don't see how that could be done if this is used as a login replacement. Still, it would be caught by fgets, so it's a non-issue. [EMAIL PROTECTED] It _won't_ be caught by fgets. See my other post. Please refer to manpages and the Standard to see what does fgets return and under what circumstances. -- dg
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 09:27:53PM +0200, Pavel Minev Penev wrote: On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for binaries. Tampering with MAC database is useless. ... [1] Message Authentication Code. One of possible ways to compute MAC is H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M is message (protected binary). Hey, I'm not very good at crypto; however, I was wondering what prevents the intruder from regenerating the MAC data-base (and what is the point of the double hashing you have stated as "H(K,H(K,M))"?). The Book (Bruce Schneier, "Applied Cryptography"): Alice concatenates K and M, and computes the one-way hash of concatenation: H(K,M). This hash is the MAC. Since Bob knows K, he can reproduce Alice's result. Mallory, who does not know K, can't. This method works with MD-strengtheninig techniques, but has serious problems. Malory can always add new blocks to the end of message and compute a valid MAC. This attack can be thwarted if you put the message length at the beginning, but Preneel is suspictios of this scheme. It is better to put the key at then end of message, H(M,K), but this has some problems as well. The following constructions seem secure: H(K1,H(K2,M)) H(K,H(K,M)) H(K,p,M,K), where p pads K to full message block. Sorry if off-topic (though a nice critical note would be fine). And don't forget to be gay (at least on Christmas), -- Pavel M. Penev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 09:27:53PM +0200, Pavel Minev Penev wrote: On Tue, Dec 26, 2000 at 05:27:07PM +0300, [EMAIL PROTECTED] wrote: Of course plain md5 hashes are not very helpful. But we can keep MAC[1] for binaries. Tampering with MAC database is useless. ... [1] Message Authentication Code. One of possible ways to compute MAC is H(K,H(K,M)) where H is one-way hash function (MD5 or better SHA), K is key, M is message (protected binary). Hey, I'm not very good at crypto; however, I was wondering what prevents the intruder from regenerating the MAC data-base (and what is the point of the double hashing you have stated as H(K,H(K,M))?). The Book (Bruce Schneier, Applied Cryptography): Alice concatenates K and M, and computes the one-way hash of concatenation: H(K,M). This hash is the MAC. Since Bob knows K, he can reproduce Alice's result. Mallory, who does not know K, can't. This method works with MD-strengtheninig techniques, but has serious problems. Malory can always add new blocks to the end of message and compute a valid MAC. This attack can be thwarted if you put the message length at the beginning, but Preneel is suspictios of this scheme. It is better to put the key at then end of message, H(M,K), but this has some problems as well. The following constructions seem secure: H(K1,H(K2,M)) H(K,H(K,M)) H(K,p,M,K), where p pads K to full message block. Sorry if off-topic (though a nice critical note would be fine). And don't forget to be gay (at least on Christmas), -- Pavel M. Penev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- dg
Re: Debian audititing tool?
On Tue, Dec 26, 2000 at 10:52:47PM +0100, Christian Kurz wrote: On 00-12-26 Peter Cordes wrote: have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't a real break against MD5. It means that you can find two messages that hash to the same value. To do so, you _have_ to choose both messages yourself. If one of the messages is /bin/su, you are almost certainly out of luck. Nobody has figured out how to make another message that collides with a given message. It only works if they create _both_ messages. Cool, would you then please explain why Bruce Schneier writes about MD5: I am wary of using MD5 in his book Applied Cryptograhy and the end of the section about MD5? Ciao Christian For some applications the collision-resistance property is critical. Simply computing and storing one-way hashes IS NOT an application which depends on this property. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- dg
