Re: init.d startup sequence for shorewall
On Fri, Dec 13, 2002 at 09:25:02AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Thu, Dec 12, 2002 at 04:18:17PM -0500, Raymond Wood wrote:
> > There have been several responses to Yogesh's question, but none
> > of them provide a clear and straightforward answer.
>
> Ok. Let me try again: this is a security risk.
>
> A gateway firewall _needs_ to be setup the following way:
>
> 0.- setup a default DROP policy, flush all policies
> 1.- startup network interfaces (but w/o forwarding)
> 2.- setup proper firewall rules
> 3.- enable forwarding
/etc/network/interfaces
pre-up
--
Pav
,.,
,``:'',
That your internet traffic is {o ! o} My GPG/PGP key is now available at
vulnarable is NOT only a joke! ] -+- [ x-hkp://search.keyserver.net:11371.
\ ! /
`-'
`shell$ gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 164C028F`
pgppKTwK1OZmW.pgp
Description: PGP signature
Re: init.d startup sequence for shorewall
On Fri, Dec 13, 2002 at 09:25:02AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Thu, Dec 12, 2002 at 04:18:17PM -0500, Raymond Wood wrote:
> > There have been several responses to Yogesh's question, but none
> > of them provide a clear and straightforward answer.
>
> Ok. Let me try again: this is a security risk.
>
> A gateway firewall _needs_ to be setup the following way:
>
> 0.- setup a default DROP policy, flush all policies
> 1.- startup network interfaces (but w/o forwarding)
> 2.- setup proper firewall rules
> 3.- enable forwarding
/etc/network/interfaces
pre-up
--
Pav
,.,
,``:'',
That your internet traffic is {o ! o} My GPG/PGP key is now available at
vulnarable is NOT only a joke! ] -+- [ x-hkp://search.keyserver.net:11371.
\ ! /
`-'
`shell$ gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 164C028F`
msg08156/pgp0.pgp
Description: PGP signature
OT: Re: cmon people
On Mon, Oct 07, 2002 at 06:39:15PM +0300, Ivan Jendov wrote:
> Received: from rams3.rasd.net (unknown [199.234.146.17])
> by murphy.debian.org (Postfix) with ESMTP id 946FC1F415
> for ; Mon, 7 Oct 2002 10:09:24 -0500
> (CDT)
> Received: from store12.cybercity.dk ([194.126.61.17]) by rams3.rasd.net with
> Microsoft SMTPSVC(5.0.2195.5329);
> Mon, 7 Oct 2002 06:12:27 -0400
>
>
> do we need to see that ? lets make a spam filters/rules for all spam context
> ... i'll thina many people can help with ideas, tools .. etc
Just do a quick search on "spam", "unsubscribe", or "procmail" on
http://lists.debian.org/search.html> to see megabytes of messages
on this topic. You can particularly see a message of mine (hey, I like
to show off :)) at
http://lists.debian.org/debian-security/2002/debian-security-200208/msg00273.html>.
A quick response is that mailing list's policy is to deliver messages as
fast as possible, and, therefore, without any moderation.
I know you probably simply wanted to make a good proposal and hope you
don't take this RTFM-like answer as an offence; howerver, I guess if I
haven't responded you would have been ignored. And how could I allow
this -- you administrate my coutry rulers' michenery:
> Ivan Jendov
> System Administrator
> Council Of Ministers
>
> www.government.bg
Best whishes to you there, and, hey, you may find it useful and fun to
use the message archives search engine from time to time.
See you soon,
--
Pav
,.,
,``:'',
That your internet traffic is {o ! o} My GPG/PGP key is now available at
vulnarable is NOT only a joke! ] -+- [ x-hkp://search.keyserver.net:11371.
\ ! /
`-'
`shell$ gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 164C028F`
pgpN29SaEb0u8.pgp
Description: PGP signature
OT: Re: cmon people
On Mon, Oct 07, 2002 at 06:39:15PM +0300, Ivan Jendov wrote:
> Received: from rams3.rasd.net (unknown [199.234.146.17])
> by murphy.debian.org (Postfix) with ESMTP id 946FC1F415
> for <[EMAIL PROTECTED]>; Mon, 7 Oct 2002 10:09:24 -0500
> (CDT)
> Received: from store12.cybercity.dk ([194.126.61.17]) by rams3.rasd.net with
> Microsoft SMTPSVC(5.0.2195.5329);
> Mon, 7 Oct 2002 06:12:27 -0400
>
>
> do we need to see that ? lets make a spam filters/rules for all spam context
> ... i'll thina many people can help with ideas, tools .. etc
Just do a quick search on "spam", "unsubscribe", or "procmail" on
http://lists.debian.org/search.html> to see megabytes of messages
on this topic. You can particularly see a message of mine (hey, I like
to show off :)) at
http://lists.debian.org/debian-security/2002/debian-security-200208/msg00273.html>.
A quick response is that mailing list's policy is to deliver messages as
fast as possible, and, therefore, without any moderation.
I know you probably simply wanted to make a good proposal and hope you
don't take this RTFM-like answer as an offence; howerver, I guess if I
haven't responded you would have been ignored. And how could I allow
this -- you administrate my coutry rulers' michenery:
> Ivan Jendov
> System Administrator
> Council Of Ministers
>
> www.government.bg
Best whishes to you there, and, hey, you may find it useful and fun to
use the message archives search engine from time to time.
See you soon,
--
Pav
,.,
,``:'',
That your internet traffic is {o ! o} My GPG/PGP key is now available at
vulnarable is NOT only a joke! ] -+- [ x-hkp://search.keyserver.net:11371.
\ ! /
`-'
`shell$ gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 164C028F`
msg07255/pgp0.pgp
Description: PGP signature
Re: OT RE: unsubscribe
On Mon, Aug 19, 2002 at 08:41:29PM +0300, Boyan Krosnov wrote: > > But all in all you can always send these posts to /dev/null > > with procmail. > Why not do it on the mailing list server instead on all those inocent > recipients? :) Filtering on a subject basis seems too dangerous to me, and filtering on a subject + body basis may still let some messages through. Anyway, the Debain mailing lists are open, non-moderated, delivering mail as quickly as possible. They allow even ads from time to time (there was a $1000 fine for commercial messages IIRC, is there still one?), so these "unsubscribe" messages are just peanuts. "Be open to everyone and everything" is part of the lists's policy, I think. In today's world of daily (or even hourly) spam and "I can't log into my Yahoo! account" messages, people have to get used quickly. Then are you really so concerned with these "unsubscribe" messages that you create threads on them (at least once a month) in the debian-*security* mailing list? Or you just like having a chat? Because that is what I am doing right now. I don't care about: > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] or about > starting the next OT flame war on debian lists, . I care about this: > Boyan Krosnov, CCIE#8701 > http://boyan.ludost.net/ > Just another techie speaking for himself HEY, BOBBY!!! I haven't heard from you since I implemeted linked lists in C macros, or maybe even since I was making the computer synthesize the sound of puking (am I starting to forget?). A nice place to meet you -- the security list. A more physical one may feel better, huh? If you happen to find yourself in one, drop a line, please! You can find me in the same old place in front of the computer. See you. To all who read me and not, best whishes and more security, -- Pav
Re: Proposal for new Security subsection for non-US
On Sun, Jun 23, 2002 at 11:49:02AM -0500, Steve Langasek wrote: > On Sun, Jun 23, 2002 at 01:25:56PM -0300, Peter Cordes wrote: > > On Sun, Jun 23, 2002 at 12:46:27AM +0300, Pavel Minev Penev wrote: > > > I would think of using xdelta, or similar to distrubute changes as > > > binary patches, since there could be a real server overload when a few > > > hundred administrators and mere people start downloading the brand new > > > deifinitions simultaneously. What about a public rsync? Maybe a usual > > > announce mailing list? > > > > In my oppinion, a package created ten minutes ago can't go into stable. > > > Even if it is a simple virus/worm/blacklist/... definion. Bugs can crawl > > > anywhere. Therefore, I don't think the proposed type of packages can > > > ever be a part of stable. I guess it should be like: use unstable for > > > just those packages, and stable for all the rest. > > > Well, woody will be the first stable release to support pinning, and this > > looks like an excellent application for it. Still, unless you can put > > rsync:// URLs in sources.list, it won't solve everything. rsync or > > something similar would save a lot of traffic for this kind of thing. > > Unfortunately, it's probably too late to integrate rsync into the whole apt > > system, so it can rsync stuff in /var/cache/apt/archives. Well, still binary patching could be implemented (although, in a rather osbscure way) using pre-install scripts which would patch the definition files. However, this would require two packages providing the same version of the definition files (a patch package and a complete new-version package) and a whole lot of patch packages dangling around. So I guess I am writing nonsense. > First thing's first: we need to have people regularly updating these > data packages before we should worry about whether we have the resources > to distribute them effectively. Though rsync might make things nicer > for end-users on low-speed connections, I think it'll be a long time > before this archive will come anywhere near the bandwidth requirements > for even a single site that publically mirrors unstable or testing. Understood. Maybe I am more a person of thinking than of practice. This is working on the ToDo list. (I'm not sure it is that hard to add an rsync method to dpkg, though). Have a nice coding, -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for new Security subsection for non-US
On Sat, Jun 22, 2002 at 12:21:12AM -0500, Steve Langasek wrote: > Hello Matthew, > > I'm glad to see others thinking along the same lines. However, > precisely because of the nature of the issues surrounding such packages > -- the need for frequent updates even when running stable, the fact that > this data should *not* be shipped on CDs, the relatively small mirror > requirements -- I believe such a repository for definition files could > thrive outside of the main Debian archive network. I'm also rather > confident that, at least initially, it will be a lot *easier* to > implement this outside of the main Debian archive network. Debian is > effective at a lot of things, but when you start talking about IDS > updates, you really want something a little more flexible and a little > less process-laden. ;) > > On Sat, Jun 22, 2002 at 03:55:46PM +1200, Matthew Grant wrote: > > > o Updating vulnerability databases does not work as generally the new > > data on the 'Net is no longer compatible with the binaries in stable. > > > o New versions have new detection algorithms, capabilities, and > > methodologies that are needed to deal with current and serious threats. > > I would hesitate to endorse providing Debian packages for such security > software if the binaries themselves really need to be updated that > frequently. Where binaries can be provided and managed through the > normal unstable->testing->stable system -- complete with security > updates from our world-class security team -- I think having > asynchronous updates to definiton files is a great boon; but where the > programs have to be updated frequently to remain useful, I would argue > that the software is simply not mature enough to receive the Debian seal > of approval at all. > > Thus, the responsibilities of the maintainers of such an archive would > not be to backport the software to stable, but to backport the > definition files to stable. I would think of using xdelta, or similar to distrubute changes as binary patches, since there could be a real server overload when a few hundred administrators and mere people start downloading the brand new deifinitions simultaneously. What about a public rsync? Maybe a usual announce mailing list? In my oppinion, a package created ten minutes ago can't go into stable. Even if it is a simple virus/worm/blacklist/... definion. Bugs can crawl anywhere. Therefore, I don't think the proposed type of packages can ever be a part of stable. I guess it should be like: use unstable for just those packages, and stable for all the rest. -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sources.list for potato
On Fri, Jun 21, 2002 at 08:22:32AM +0900, Olaf Meeuwissen wrote: > Mike Dresser <[EMAIL PROTECTED]> writes: > > > Hate to beat a dead horse, but > > > > > > deb http://http.us.debian.org/debian potato main contrib non-free > > deb http://http.us.debian.org/debian dists/potato-proposed-updates/ > > > > deb http://non-us.debian.org/debian-non-US potato/non-US main contrib > > non-free > > deb http://non-us.debian.org/debian-security potato/updates main contrib > > non-free > > > > deb http://security.debian.org/debian-security potato/updates main contrib > > non-free > > > > > > is all I need on my sources.list for potato, right? > > > > And when I move to woody someday, just s/potato/woody/, correct? > > For a truly stable Debian system, drop > > deb http://http.us.debian.org/debian dists/potato-proposed-updates/ > > (wait for official release updates) and then just s/potato/stable/g. > Note that non-US is being phased out. And there is no deb http://non-us.debian.org/debian-security unstable/updates main contrib non-free , is it? -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT-GET Problems
On Thu, May 02, 2002 at 06:54:38PM -0700, Mike Shepherd wrote: > # apt-get install uucp > Reading Package Lists... Done > Building Dependency Tree... Done > The following NEW packages will be installed: > uucp > 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > E: Could not get lock /var/cache/apt/archives/lock - open (22 Invalid > argument) > E: Unable to lock the download directory > > [EMAIL PROTECTED]:pts/0-1!/var/cache/apt/archives] > # mount > /dev/hda5 on / type ext2 (rw,errors=remount-ro) > proc on /proc type proc (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > 192.168.2.15:/home on /home type nfs > (rw,noexec,nosuid,nodev,rsize=8192,wsize=81 > 92,addr=192.168.2.15) > 192.168.2.15:/var/cache/apt/archives on /var/cache/apt/archives type nfs > (rw,noe > xec,nosuid,nodev,rsize=8192,wsize=8192,addr=192.168.2.15) This sounds like an NFS locking problem. It will surely happen if you try to use `dpkg` (either through `apt-get`, or not) on both machines at the same time. Otherwise, it may be an NFS server problem, or a kernerl problem (regarding NFS locking support). Someone knows something more prcise? -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT-GET Problems
On Thu, May 02, 2002 at 06:54:38PM -0700, Mike Shepherd wrote: > # apt-get install uucp > Reading Package Lists... Done > Building Dependency Tree... Done > The following NEW packages will be installed: > uucp > 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > E: Could not get lock /var/cache/apt/archives/lock - open (22 Invalid argument) > E: Unable to lock the download directory > > [root@generic:pts/0-1!/var/cache/apt/archives] > # mount > /dev/hda5 on / type ext2 (rw,errors=remount-ro) > proc on /proc type proc (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > 192.168.2.15:/home on /home type nfs (rw,noexec,nosuid,nodev,rsize=8192,wsize=81 > 92,addr=192.168.2.15) > 192.168.2.15:/var/cache/apt/archives on /var/cache/apt/archives type nfs (rw,noe > xec,nosuid,nodev,rsize=8192,wsize=8192,addr=192.168.2.15) This sounds like an NFS locking problem. It will surely happen if you try to use `dpkg` (either through `apt-get`, or not) on both machines at the same time. Otherwise, it may be an NFS server problem, or a kernerl problem (regarding NFS locking support). Someone knows something more prcise? -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cups security
On Thu, Apr 11, 2002 at 09:56:51AM -0500, Torrin wrote: > Good morning everybody, well at least morning over here in Cali. For > everybody else, Good afternoon, good evening and good night. :)) Hi, pal. > Also, when I installed cups it said something about me needing to do a . > . . > > route add -net 224.0.0.0 netmask 240.0.0.0 dev > > What's up with that? I didn't see anything in the doc about that > either. The "route" line is going to add an entry in the kernel's routing table. This entry would make the kernel think it is running on a host which is in the network 0xE?.???.???.??? where 0xE? is in hexadecimal and the "?" can match any number of the addressing IP. Moreover, the kernel is going to redirect all packets received by it to the network interface "". Sorry, if I'm not of much help, but I am using LPRNG and can't really help you with cups. Generally, if you want to use the server on your host only, you should set up a firewall. Until someone helps you, -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cups security
On Thu, Apr 11, 2002 at 09:56:51AM -0500, Torrin wrote: > Good morning everybody, well at least morning over here in Cali. For > everybody else, Good afternoon, good evening and good night. :)) Hi, pal. > Also, when I installed cups it said something about me needing to do a . > . . > > route add -net 224.0.0.0 netmask 240.0.0.0 dev > > What's up with that? I didn't see anything in the doc about that > either. The "route" line is going to add an entry in the kernel's routing table. This entry would make the kernel think it is running on a host which is in the network 0xE?.???.???.??? where 0xE? is in hexadecimal and the "?" can match any number of the addressing IP. Moreover, the kernel is going to redirect all packets received by it to the network interface "". Sorry, if I'm not of much help, but I am using LPRNG and can't really help you with cups. Generally, if you want to use the server on your host only, you should set up a firewall. Until someone helps you, -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security problem in PHP3+Postgres with Potato?
On Mon, Mar 25, 2002 at 04:54:37PM +0100, Beno?t Sibaud wrote:
> I think I found a security problem in PHP3+postgres+apache shipped with
> Potato.
>
> Correct me if I'm wrong, but the following code should support any $var.
> If you uncomment the client_encoding line, I'm able to execute any
> request I want with the good $var.
>
> %<--
> $conn = pg_connect("dbname=" . BASE_DOC . " port=" . BASE_PORT
>. " user=" . BASE_USER);
> $var="X";
> //pg_exec($conn, "SET client_encoding = 'LATIN1'");
> $requete = "SELECT col FROM tab WHERE col='" . addslashes($var) . "'";
> echo $requete;
> $query = pg_exec($conn, $requete);
> %<--
Sorry, if I'm too blind, but what can you execute using $var?
--
Pav
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security problem in PHP3+Postgres with Potato?
On Mon, Mar 25, 2002 at 04:54:37PM +0100, Beno?t Sibaud wrote:
> I think I found a security problem in PHP3+postgres+apache shipped with
> Potato.
>
> Correct me if I'm wrong, but the following code should support any $var.
> If you uncomment the client_encoding line, I'm able to execute any
> request I want with the good $var.
>
> %<--
> $conn = pg_connect("dbname=" . BASE_DOC . " port=" . BASE_PORT
>. " user=" . BASE_USER);
> $var="X";
> //pg_exec($conn, "SET client_encoding = 'LATIN1'");
> $requete = "SELECT col FROM tab WHERE col='" . addslashes($var) . "'";
> echo $requete;
> $query = pg_exec($conn, $requete);
> %<--
Sorry, if I'm too blind, but what can you execute using $var?
--
Pav
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: protection against buffer overflows
On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> Hi all !
>
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and maybe Saint Jude.
>
> Has anyone any interesting comments about theses methods ?
I would like to comment on another method, if you don't mind. I few
years ago I was after buffer overflows just as you. What I wanted was to
make a programme which parses the C (or whatever) source code and checks
if it is possible a buffer overflow to occur if the programme is fed
suitable input data. The idea was simple:
1. For each code block (what is put in curly braces
("{", "}") in C) check what condition(s) should be met so that
an overflow occurs.
2. Then exclude those conditions at which the block is
not entered at all.
3. Repeat this procedure until the main () function's
block is finished.
4. Do this for all blocks in the source code.
Of course this may be hard to achieve if the, let's say, C code is mixed
with assembler or even machine code; however, it seems applicable for
most "normal" programmes.
A few examples:
/* Fool a programme using the above idea: */
typedef void(*VoidFunc) (void);
int main (void)
{
charmachine_code [] = "\x00\x01";
VoidFuncmachine_func = (VoidFunc) machine_code;
machine_func ();
return (0);
}
/* End of example 1. */
/* Overflow that would be caught: */
#include
#include
int main (int argc, char *argv[])
{
/* Always enered. */
/* argv has argc elements (by
definition). */
char*buf;
unsigned intstr_len1, str_len2, c;
if ( argc != 3 ) {
/* Entered when argc != 3. */
return (1); /* The execution of the enclosing
block is terminated. */
}
/* Reached when !(argc != 3) <=>
argc == 3. */
str_len1 = strlen (argv [0]); /* Overflow when:
1. 0 > argc-1 <=> 0 > 2. */
/* => No overflow. */
str_len2 = strlen (argv [1]); /* Overflow when:
1. 1 > argc-1 <=> 1 > 2. */
/* => No overflow. */
buf = (char*) malloc (sizeof (char) * (str_len1+str_len2));
/* buf has
(sizeof (char)*(str_len1+str_len2)) /
sizeof (char) ==
(str_len1+str_len2) elements. */
for ( c = 0; c < str_len1; c++ ) {
/* Entered when c < str_len1. */
buf [c] = argv [0][c]; /* Overflow when:
1. c >= (str_len1+str_len2)
2. 0 > argc-1 <=> 0 > 2.
3. c > strlen (argv [0]) <=>
c > str_len1. */
/* => No overflow. */
}
/* Reached when c == str_len1. */
for ( c = 0; c < str_len2; c++ ) {
/* Entered when c < str_len2. */
buf [c+str_len1] = argv [1][c];
/* Overflow when:
1. c+str_len1 >= (str_len1+str_len2)
<=> c >= str_len2.
2. 1 > argc-1 <=> 1 > 2.
3. c > strlen (argv [1]) <=>
c > str_len2. */
/* => No overflow. */
}
/* Reached when c == str_len2. */
buf [c+str_len1] = '\0';/* Overflow when:
1. c+str_len1 >= (str_len1+str_len2)
<=> c >= str_len2 */
/* => Overflow, because of 1. */
return (0); /* End of processing. */
}
/* End of example 2. */
I have wasted so much of your time in the hope that someone might get
interested and volunteer for creating such a tool. I myself gave up
before finishing ev
Re: protection against buffer overflows
On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> Hi all !
>
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and maybe Saint Jude.
>
> Has anyone any interesting comments about theses methods ?
I would like to comment on another method, if you don't mind. I few
years ago I was after buffer overflows just as you. What I wanted was to
make a programme which parses the C (or whatever) source code and checks
if it is possible a buffer overflow to occur if the programme is fed
suitable input data. The idea was simple:
1. For each code block (what is put in curly braces
("{", "}") in C) check what condition(s) should be met so that
an overflow occurs.
2. Then exclude those conditions at which the block is
not entered at all.
3. Repeat this procedure until the main () function's
block is finished.
4. Do this for all blocks in the source code.
Of course this may be hard to achieve if the, let's say, C code is mixed
with assembler or even machine code; however, it seems applicable for
most "normal" programmes.
A few examples:
/* Fool a programme using the above idea: */
typedef void(*VoidFunc) (void);
int main (void)
{
charmachine_code [] = "\x00\x01";
VoidFuncmachine_func = (VoidFunc) machine_code;
machine_func ();
return (0);
}
/* End of example 1. */
/* Overflow that would be caught: */
#include
#include
int main (int argc, char *argv[])
{
/* Always enered. */
/* argv has argc elements (by
definition). */
char*buf;
unsigned intstr_len1, str_len2, c;
if ( argc != 3 ) {
/* Entered when argc != 3. */
return (1); /* The execution of the enclosing
block is terminated. */
}
/* Reached when !(argc != 3) <=>
argc == 3. */
str_len1 = strlen (argv [0]); /* Overflow when:
1. 0 > argc-1 <=> 0 > 2. */
/* => No overflow. */
str_len2 = strlen (argv [1]); /* Overflow when:
1. 1 > argc-1 <=> 1 > 2. */
/* => No overflow. */
buf = (char*) malloc (sizeof (char) * (str_len1+str_len2));
/* buf has
(sizeof (char)*(str_len1+str_len2)) /
sizeof (char) ==
(str_len1+str_len2) elements. */
for ( c = 0; c < str_len1; c++ ) {
/* Entered when c < str_len1. */
buf [c] = argv [0][c]; /* Overflow when:
1. c >= (str_len1+str_len2)
2. 0 > argc-1 <=> 0 > 2.
3. c > strlen (argv [0]) <=>
c > str_len1. */
/* => No overflow. */
}
/* Reached when c == str_len1. */
for ( c = 0; c < str_len2; c++ ) {
/* Entered when c < str_len2. */
buf [c+str_len1] = argv [1][c];
/* Overflow when:
1. c+str_len1 >= (str_len1+str_len2)
<=> c >= str_len2.
2. 1 > argc-1 <=> 1 > 2.
3. c > strlen (argv [1]) <=>
c > str_len2. */
/* => No overflow. */
}
/* Reached when c == str_len2. */
buf [c+str_len1] = '\0';/* Overflow when:
1. c+str_len1 >= (str_len1+str_len2)
<=> c >= str_len2 */
/* => Overflow, because of 1. */
return (0); /* End of processing. */
}
/* End of example 2. */
I have wasted so much of your time in the hope that someone might get
interested and volunteer for creating such a tool. I myself gave up
before finishing e
Re: A 2.4.[57] kernel crypto problem
On Mon, Jan 07, 2002 at 03:09:07PM +, Alexander Clouter wrote: > On Jan 06, Pavel Minev Penev wrote: > > > > 1. Generate billions of passwords. > > For each of them: > > 1. Setup a loop device. > > 2. Read the block after the 1024-th byte and check it > > for Ext2/Ext3's magic ID. > > If the ID matches: > > 1. Print the password. > > 3. Deconfigure the loop device. > > The brute-forcer works fine for short periods of time. > > > > I've tried this on kernels 2.4.15 and 2.4.17, it's all the same > > (although the 2.4.17 Changelog says about a number of bug-fixes in the > > loop-back driver). > > > > I was wondering if you could tell me about any known or unknown problems > > with the kernel crypto, or help me realise my stupidity. > > > there are only 8 loop devicesdo you know this? Yes. What makes you think I don't? > Another thing (which has already been mentioned) is that you may be not > closing the tasks properly, and then loop gets very upset as it hasn't been > shutdown properlyor something :) You may of found a race condition After running the brute-forcer for short the loop device seems absolutely normal. `losetup` reports it as unassigned, I can mount volumes through it, etc. I took the code from `losetup` (lomount.c), so I suppose the problem is elsewhere. Only I don't know how to investigate. -- Pav
Re: A 2.4.[57] kernel crypto problem
On Mon, Jan 07, 2002 at 07:59:35AM -0500, Anthony DeRobertis wrote: > > On Sunday, January 6, 2002, at 04:00 , Pavel Minev Penev wrote: > > >There are about 3304 proceses with sequential PIDs and names of > >"[loop7 ]", and are all zombies. > > Are you calling fork in your code? Are you calling waitpid or friends? No fork/clone/waitpid/pthread*/exec/etc. I don't need these. As I have shown on the scheme I simply generate a password, configure a loop device, read the ext2/ext3 super-block from it and test it for the ext2/ext3 magic ID. The functions used are: open (), close (), ioctl (), read (), malloc (), free (), printf (), fprintf (). > Who's children are those? (try ps fxa) `lo_bruteforce` under X, canceled before a hang-up: $ ps fxa [snip] 3427 ?S 0:03 konsole %i %m 3428 pts/6S 0:00 \_ /bin/bash 3443 pts/6S 0:00 \_ -su 13060 pts/6R 0:01 \_ ./lo_bruteforce testdev /dev/loop7 /var/tmp/lo_bruteforce.sess 13061 ?Z< 0:00 \_ [loop7 ] 13062 ?Z< 0:00 \_ [loop7 ] 13063 ?Z< 0:00 \_ [loop7 ] 13064 ?Z< 0:00 \_ [loop7 ] 13065 ?Z< 0:00 \_ [loop7 ] 13066 ?Z< 0:00 \_ [loop7 ] 13067 ?Z< 0:00 \_ [loop7 ] 13068 ?Z< 0:00 \_ [loop7 ] 13069 ?Z< 0:00 \_ [loop7 ] 13070 ?Z< 0:00 \_ [loop7 ] 13071 ?Z< 0:00 \_ [loop7 ] 13072 ?Z< 0:00 \_ [loop7 ] 13073 ?Z< 0:00 \_ [loop7 ] 13074 ?Z< 0:00 \_ [loop7 ] 13075 ?Z< 0:00 \_ [loop7 ] 13076 ?Z< 0:00 \_ [loop7 ] 13077 ?Z< 0:00 \_ [loop7 ] 13078 ?Z< 0:00 \_ [loop7 ] 13079 ?Z< 0:00 \_ [loop7 ] 13080 ?Z< 0:00 \_ [loop7 ] 13081 ?Z< 0:00 \_ [loop7 ] 13082 ?Z< 0:00 \_ [loop7 ] 13083 ?Z< 0:00 \_ [loop7 ] 13084 ?Z< 0:00 \_ [loop7 ] 13085 ?Z< 0:00 \_ [loop7 ] 13086 ?Z< 0:00 \_ [loop7 ] 13087 ?Z< 0:00 \_ [loop7 ] 13088 ?Z< 0:00 \_ [loop7 ] 13089 ?Z< 0:00 \_ [loop7 ] 13090 ?Z< 0:00 \_ [loop7 ] 13091 ?Z< 0:00 \_ [loop7 ] 13092 ?Z< 0:00 \_ [loop7 ] 13093 ?Z< 0:00 \_ [loop7 ] 13094 ?Z< 0:00 \_ [loop7 ] 13095 ?Z< 0:00 \_ [loop7 ] 13096 ?Z< 0:00 \_ [loop7 ] 13097 ?Z< 0:00 \_ [loop7 ] 13098 ?Z< 0:00 \_ [loop7 ] 13099 ?Z< 0:00 \_ [loop7 ] 13100 ?Z< 0:00 \_ [loop7 ] 13101 ?Z< 0:00 \_ [loop7 ] 13102 ?Z< 0:00 \_ [loop7 ] 13103 ?Z< 0:00 \_ [loop7 ] 13104 ?Z< 0:00 \_ [loop7 ] 13105 ?Z< 0:00 \_ [loop7 ] 13106 ?Z< 0:00 \_ [loop7 ] 13107 ?Z< 0:00 \_ [loop7 ] 13108 ?Z< 0:00 \_ [loop7 ] 13109 ?Z< 0:00 \_ [loop7 ] 13110 ?Z< 0:00 \_ [loop7 ] 13111 ?Z< 0:00 \_ [loop7 ] 13112 ?Z< 0:00 \_ [loop7 ] 13113 ?Z< 0:00 \_ [loop7 ] 13114 ?Z< 0:00 \_ [loop7 ] 13115 ?Z< 0:00 \_ [loop7 ] 13116 ?Z< 0:00 \_ [loop7 ] 13117 ?Z< 0:00 \_ [loop7 ] 13118 ?Z< 0:00 \_ [loop7 ] 13119 ?Z< 0:00 \_ [loop7 ] 13120 ?Z< 0:00 \_ [loop7 ] 13121 ?Z< 0:00 \_ [loop7 ] 13122 ?Z< 0:00 \_ [loop7 ] 13123 ?Z< 0:00 \_ [loop7 ] 13124 ?Z< 0:00 \_ [loop7 ] 13125 ?Z< 0:00 \_ [loop7 ] 13126 ?Z< 0:00 \_ [loop7 ] 13127 ?Z< 0:00 \_ [loop7 ] 13128 ?Z< 0:00 \_ [loo
Re: A 2.4.[57] kernel crypto problem
On Sun, Jan 06, 2002 at 04:10:12AM -0700, Stefan Srdic wrote: > On January 6, 2002 02:00 pm, Pavel Minev Penev wrote: > > > > Hello. > > > > I had a peculiar experience with a password (forgot it). It is the > > password for an AE > > S-encrypted partition on my HDD. I am using the loop > > device and the international kernel patch. I wrote a brute-forcer > > (didn't find docs and stole a lot of code from mount and losetup). > > > > The problem is that when I leave the brute-forcer working for a longer > > time (about 5 seconds on my 750 MHz Duron) when I press Ctrl-C (the > > brute-forcer catches the signal and tries to save the session) the > > kernel seems to deadlock. It is most probably the loop device driver. > > There are about 3304 proceses with sequential PIDs and names of > > "[loop7 ]", and are all zombies. If I try to start an app. as > > root I get something like "fork: resource temporarily unavailable", or > > "INIT: cannot fork; retrying...". Also, I can't `losetup /dev/loop7`, > > since it pauses, issuing nothing. As a normal user I seem to be able to > > work as usual. After a short period of time `init` seems to start > > functioning and switch the run-level. The brute-forcer works as follows: > > 1. Generate billions of passwords. > > For each of them: > > 1. Setup a loop device. > > 2. Read the block after the 1024-th byte and check it > > for Ext2/Ext3's magic ID. > > If the ID matches: > > 1. Print the password. > > 3. Deconfigure the loop device. > > The brute-forcer works fine for short periods of time. > > > > I've tried this on kernels 2.4.15 and 2.4.17, it's all the same > > (although the 2.4.17 Changelog says about a number of bug-fixes in the > > loop-back driver). > > > > I was wonder > > ing if you could tell me about any known or unknown problems > > with the kernel crypto, or help me realise my stupidity. > > > > Comment: Sorry if this is too off-topic, I could post it to the Linux > > kernel mailing list if you prefer. > > There's a warning in announce.txt in the testing directory that you might not > have seen: > > *WARNING* this is meant for the brave ones (read beta-testers ;), which > want to do some tests, and hopefully report back any problems they > encounter! > > Perhaps just using the standalone loop-aes module would be better in your > case: > > http://loop-aes.sourceforge.net/ > > It's worth a try. Yes. This is great, it has a fabulous performance. If I could only find some docs on the API I would be very thankful (the kernel module's sources are huge to read). Thanks, -- Pav
Re: A 2.4.[57] kernel crypto problem
On Mon, Jan 07, 2002 at 03:09:07PM +, Alexander Clouter wrote: > On Jan 06, Pavel Minev Penev wrote: > > > > 1. Generate billions of passwords. > > For each of them: > > 1. Setup a loop device. > > 2. Read the block after the 1024-th byte and check it > > for Ext2/Ext3's magic ID. > > If the ID matches: > > 1. Print the password. > > 3. Deconfigure the loop device. > > The brute-forcer works fine for short periods of time. > > > > I've tried this on kernels 2.4.15 and 2.4.17, it's all the same > > (although the 2.4.17 Changelog says about a number of bug-fixes in the > > loop-back driver). > > > > I was wondering if you could tell me about any known or unknown problems > > with the kernel crypto, or help me realise my stupidity. > > > there are only 8 loop devicesdo you know this? Yes. What makes you think I don't? > Another thing (which has already been mentioned) is that you may be not > closing the tasks properly, and then loop gets very upset as it hasn't been > shutdown properlyor something :) You may of found a race condition After running the brute-forcer for short the loop device seems absolutely normal. `losetup` reports it as unassigned, I can mount volumes through it, etc. I took the code from `losetup` (lomount.c), so I suppose the problem is elsewhere. Only I don't know how to investigate. -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A 2.4.[57] kernel crypto problem
On Mon, Jan 07, 2002 at 07:59:35AM -0500, Anthony DeRobertis wrote: > > On Sunday, January 6, 2002, at 04:00 , Pavel Minev Penev wrote: > > >There are about 3304 proceses with sequential PIDs and names of > >"[loop7 ]", and are all zombies. > > Are you calling fork in your code? Are you calling waitpid or friends? No fork/clone/waitpid/pthread*/exec/etc. I don't need these. As I have shown on the scheme I simply generate a password, configure a loop device, read the ext2/ext3 super-block from it and test it for the ext2/ext3 magic ID. The functions used are: open (), close (), ioctl (), read (), malloc (), free (), printf (), fprintf (). > Who's children are those? (try ps fxa) `lo_bruteforce` under X, canceled before a hang-up: $ ps fxa [snip] 3427 ?S 0:03 konsole %i %m 3428 pts/6S 0:00 \_ /bin/bash 3443 pts/6S 0:00 \_ -su 13060 pts/6R 0:01 \_ ./lo_bruteforce testdev /dev/loop7 /var/tmp/lo_bruteforce.sess 13061 ?Z< 0:00 \_ [loop7 ] 13062 ?Z< 0:00 \_ [loop7 ] 13063 ?Z< 0:00 \_ [loop7 ] 13064 ?Z< 0:00 \_ [loop7 ] 13065 ?Z< 0:00 \_ [loop7 ] 13066 ?Z< 0:00 \_ [loop7 ] 13067 ?Z< 0:00 \_ [loop7 ] 13068 ?Z< 0:00 \_ [loop7 ] 13069 ?Z< 0:00 \_ [loop7 ] 13070 ?Z< 0:00 \_ [loop7 ] 13071 ?Z< 0:00 \_ [loop7 ] 13072 ?Z< 0:00 \_ [loop7 ] 13073 ?Z< 0:00 \_ [loop7 ] 13074 ?Z< 0:00 \_ [loop7 ] 13075 ?Z< 0:00 \_ [loop7 ] 13076 ?Z< 0:00 \_ [loop7 ] 13077 ?Z< 0:00 \_ [loop7 ] 13078 ?Z< 0:00 \_ [loop7 ] 13079 ?Z< 0:00 \_ [loop7 ] 13080 ?Z< 0:00 \_ [loop7 ] 13081 ?Z< 0:00 \_ [loop7 ] 13082 ?Z< 0:00 \_ [loop7 ] 13083 ?Z< 0:00 \_ [loop7 ] 13084 ?Z< 0:00 \_ [loop7 ] 13085 ?Z< 0:00 \_ [loop7 ] 13086 ?Z< 0:00 \_ [loop7 ] 13087 ?Z< 0:00 \_ [loop7 ] 13088 ?Z< 0:00 \_ [loop7 ] 13089 ?Z< 0:00 \_ [loop7 ] 13090 ?Z< 0:00 \_ [loop7 ] 13091 ?Z< 0:00 \_ [loop7 ] 13092 ?Z< 0:00 \_ [loop7 ] 13093 ?Z< 0:00 \_ [loop7 ] 13094 ?Z< 0:00 \_ [loop7 ] 13095 ?Z< 0:00 \_ [loop7 ] 13096 ?Z< 0:00 \_ [loop7 ] 13097 ?Z< 0:00 \_ [loop7 ] 13098 ?Z< 0:00 \_ [loop7 ] 13099 ?Z< 0:00 \_ [loop7 ] 13100 ?Z< 0:00 \_ [loop7 ] 13101 ?Z< 0:00 \_ [loop7 ] 13102 ?Z< 0:00 \_ [loop7 ] 13103 ?Z< 0:00 \_ [loop7 ] 13104 ?Z< 0:00 \_ [loop7 ] 13105 ?Z< 0:00 \_ [loop7 ] 13106 ?Z< 0:00 \_ [loop7 ] 13107 ?Z< 0:00 \_ [loop7 ] 13108 ?Z< 0:00 \_ [loop7 ] 13109 ?Z< 0:00 \_ [loop7 ] 13110 ?Z< 0:00 \_ [loop7 ] 13111 ?Z< 0:00 \_ [loop7 ] 13112 ?Z< 0:00 \_ [loop7 ] 13113 ?Z< 0:00 \_ [loop7 ] 13114 ?Z< 0:00 \_ [loop7 ] 13115 ?Z< 0:00 \_ [loop7 ] 13116 ?Z< 0:00 \_ [loop7 ] 13117 ?Z< 0:00 \_ [loop7 ] 13118 ?Z< 0:00 \_ [loop7 ] 13119 ?Z< 0:00 \_ [loop7 ] 13120 ?Z< 0:00 \_ [loop7 ] 13121 ?Z< 0:00 \_ [loop7 ] 13122 ?Z< 0:00 \_ [loop7 ] 13123 ?Z< 0:00 \_ [loop7 ] 13124 ?Z< 0:00 \_ [loop7 ] 13125 ?Z< 0:00 \_ [loop7 ] 13126 ?Z< 0:00 \_ [loop7 ] 13127 ?Z< 0:00 \_ [loop7 ] 13128 ?Z< 0:00 \_ [loo
Re: A 2.4.[57] kernel crypto problem
On Sun, Jan 06, 2002 at 04:10:12AM -0700, Stefan Srdic wrote: > On January 6, 2002 02:00 pm, Pavel Minev Penev wrote: > > > > Hello. > > > > I had a peculiar experience with a password (forgot it). It is the > > password for an AE > > S-encrypted partition on my HDD. I am using the loop > > device and the international kernel patch. I wrote a brute-forcer > > (didn't find docs and stole a lot of code from mount and losetup). > > > > The problem is that when I leave the brute-forcer working for a longer > > time (about 5 seconds on my 750 MHz Duron) when I press Ctrl-C (the > > brute-forcer catches the signal and tries to save the session) the > > kernel seems to deadlock. It is most probably the loop device driver. > > There are about 3304 proceses with sequential PIDs and names of > > "[loop7 ]", and are all zombies. If I try to start an app. as > > root I get something like "fork: resource temporarily unavailable", or > > "INIT: cannot fork; retrying...". Also, I can't `losetup /dev/loop7`, > > since it pauses, issuing nothing. As a normal user I seem to be able to > > work as usual. After a short period of time `init` seems to start > > functioning and switch the run-level. The brute-forcer works as follows: > > 1. Generate billions of passwords. > > For each of them: > > 1. Setup a loop device. > > 2. Read the block after the 1024-th byte and check it > > for Ext2/Ext3's magic ID. > > If the ID matches: > > 1. Print the password. > > 3. Deconfigure the loop device. > > The brute-forcer works fine for short periods of time. > > > > I've tried this on kernels 2.4.15 and 2.4.17, it's all the same > > (although the 2.4.17 Changelog says about a number of bug-fixes in the > > loop-back driver). > > > > I was wonder > > ing if you could tell me about any known or unknown problems > > with the kernel crypto, or help me realise my stupidity. > > > > Comment: Sorry if this is too off-topic, I could post it to the Linux > > kernel mailing list if you prefer. > > There's a warning in announce.txt in the testing directory that you might not > have seen: > > *WARNING* this is meant for the brave ones (read beta-testers ;), which > want to do some tests, and hopefully report back any problems they > encounter! > > Perhaps just using the standalone loop-aes module would be better in your > case: > > http://loop-aes.sourceforge.net/ > > It's worth a try. Yes. This is great, it has a fabulous performance. If I could only find some docs on the API I would be very thankful (the kernel module's sources are huge to read). Thanks, -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A 2.4.[57] kernel crypto problem
Hello. I had a peculiar experience with a password (forgot it). It is the password for an AES-encrypted partition on my HDD. I am using the loop device and the international kernel patch. I wrote a brute-forcer (didn't find docs and stole a lot of code from mount and losetup). The problem is that when I leave the brute-forcer working for a longer time (about 5 seconds on my 750 MHz Duron) when I press Ctrl-C (the brute-forcer catches the signal and tries to save the session) the kernel seems to deadlock. It is most probably the loop device driver. There are about 3304 proceses with sequential PIDs and names of "[loop7 ]", and are all zombies. If I try to start an app. as root I get something like "fork: resource temporarily unavailable", or "INIT: cannot fork; retrying...". Also, I can't `losetup /dev/loop7`, since it pauses, issuing nothing. As a normal user I seem to be able to work as usual. After a short period of time `init` seems to start functioning and switch the run-level. The brute-forcer works as follows: 1. Generate billions of passwords. For each of them: 1. Setup a loop device. 2. Read the block after the 1024-th byte and check it for Ext2/Ext3's magic ID. If the ID matches: 1. Print the password. 3. Deconfigure the loop device. The brute-forcer works fine for short periods of time. I've tried this on kernels 2.4.15 and 2.4.17, it's all the same (although the 2.4.17 Changelog says about a number of bug-fixes in the loop-back driver). I was wondering if you could tell me about any known or unknown problems with the kernel crypto, or help me realise my stupidity. Comment: Sorry if this is too off-topic, I could post it to the Linux kernel mailing list if you prefer. -- Pav
A 2.4.[57] kernel crypto problem
Hello. I had a peculiar experience with a password (forgot it). It is the password for an AES-encrypted partition on my HDD. I am using the loop device and the international kernel patch. I wrote a brute-forcer (didn't find docs and stole a lot of code from mount and losetup). The problem is that when I leave the brute-forcer working for a longer time (about 5 seconds on my 750 MHz Duron) when I press Ctrl-C (the brute-forcer catches the signal and tries to save the session) the kernel seems to deadlock. It is most probably the loop device driver. There are about 3304 proceses with sequential PIDs and names of "[loop7 ]", and are all zombies. If I try to start an app. as root I get something like "fork: resource temporarily unavailable", or "INIT: cannot fork; retrying...". Also, I can't `losetup /dev/loop7`, since it pauses, issuing nothing. As a normal user I seem to be able to work as usual. After a short period of time `init` seems to start functioning and switch the run-level. The brute-forcer works as follows: 1. Generate billions of passwords. For each of them: 1. Setup a loop device. 2. Read the block after the 1024-th byte and check it for Ext2/Ext3's magic ID. If the ID matches: 1. Print the password. 3. Deconfigure the loop device. The brute-forcer works fine for short periods of time. I've tried this on kernels 2.4.15 and 2.4.17, it's all the same (although the 2.4.17 Changelog says about a number of bug-fixes in the loop-back driver). I was wondering if you could tell me about any known or unknown problems with the kernel crypto, or help me realise my stupidity. Comment: Sorry if this is too off-topic, I could post it to the Linux kernel mailing list if you prefer. -- Pav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH and RSA
On Mon, Feb 19, 2001 at 01:21:45PM -0500, Dan Hutchinson wrote: > Without SSH enabled, I was able to pass my root user account from one > trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. > #cat .rhost > Doctor > > #cat /etc/host.equiv > Doctor root > > For example, Doctor would be the solaris hostname and root would be the > account. This leaves a big security hole, so I only activate it when > I am doing backups for about 4-5 hours each month. Maybe someone on > the list can help with the RSA since I am fairly new in that field also > > Dan > > Duane Powers <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Recently I was made administrator over a dozen Solaris boxen > > The prior admin was offsite and used ssh with rsa keys to access the > > boxes. > > He allowed root login, and used the RSA key functionality to keep the > > root > > password safe. > > I am not as mature as he was regarding ssh and have only used > > ssh as a plug in replacement to telnet, > > > p/w during > > ssh-keygen> and simply access the boxes as follows: ssh -l > > then I login using the normal p/w that is local to the box. I have > > found > > that he did > > not need to transmit the local password over the tunnel, but rather > > used > > RSA to > > verify his identity, but I can't find documentation on how to do it. > > > > > Security> does anyone have any information on how I can implement the > > > > same safeguards? Or where I can at least find some documentation on > > > > practical ssh implementation. > > > > As always, You guys are great, thanks in advance for the help, Hi, guys. Here's what I've got: <-- terminal copy start: --> $ ssh -v SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0. <-- terminal copy snip --> $ man ssh SSH(1) System Reference Manual SSH(1) NAME ssh - OpenSSH secure shell client (remote login program) <-- terminal copy snip --> DESCRIPTION <-- terminal copy snip --> SSH protocol version 1 <-- terminal copy snip --> As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal- lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. <-- terminal copy snip --> <-- terminal copy end: --> I also suggest re-reading the ssh-keygen(1) manual page. To use RSA/DSA authentication you need to generate a personal log-in key pair (via ssh-keygen). Then, copy your public key to the remote machine's "$HOME/.ssh/authorized_keys" for RSA or "$HOME/.ssh/authorized_keys2" for DSA where "$HOME" is the home directory for the user as who you want to log in on the remote machine. After this step, assuming the other configuration is fine, an "$ ssh -l remote_user_name remote_host_name" should be about enough to log in to the remote machine. A piece of advice: if you want security, read all the manual documentation you have about ssh. Good luck, -- Pavel M. Penev
Re: SSH and RSA
On Mon, Feb 19, 2001 at 01:21:45PM -0500, Dan Hutchinson wrote: > Without SSH enabled, I was able to pass my root user account from one > trusted Solaris Box to another with an /.rhost and /etc/host.equiv file. > #cat .rhost > Doctor > > #cat /etc/host.equiv > Doctor root > > For example, Doctor would be the solaris hostname and root would be the > account. This leaves a big security hole, so I only activate it when > I am doing backups for about 4-5 hours each month. Maybe someone on > the list can help with the RSA since I am fairly new in that field also > > Dan > > Duane Powers <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Recently I was made administrator over a dozen Solaris boxen > > The prior admin was offsite and used ssh with rsa keys to access the > > boxes. > > He allowed root login, and used the RSA key functionality to keep the > > root > > password safe. > > I am not as mature as he was regarding ssh and have only used > > ssh as a plug in replacement to telnet, > > > p/w during > > ssh-keygen> and simply access the boxes as follows: ssh -l > > then I login using the normal p/w that is local to the box. I have > > found > > that he did > > not need to transmit the local password over the tunnel, but rather > > used > > RSA to > > verify his identity, but I can't find documentation on how to do it. > > > > > Security> does anyone have any information on how I can implement the > > > > same safeguards? Or where I can at least find some documentation on > > > > practical ssh implementation. > > > > As always, You guys are great, thanks in advance for the help, Hi, guys. Here's what I've got: <-- terminal copy start: --> $ ssh -v SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0. <-- terminal copy snip --> $ man ssh SSH(1) System Reference Manual SSH(1) NAME ssh - OpenSSH secure shell client (remote login program) <-- terminal copy snip --> DESCRIPTION <-- terminal copy snip --> SSH protocol version 1 <-- terminal copy snip --> As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the chal- lenge using the private key, proving that he/she knows the private key but without disclosing it to the server. <-- terminal copy snip --> <-- terminal copy end: --> I also suggest re-reading the ssh-keygen(1) manual page. To use RSA/DSA authentication you need to generate a personal log-in key pair (via ssh-keygen). Then, copy your public key to the remote machine's "$HOME/.ssh/authorized_keys" for RSA or "$HOME/.ssh/authorized_keys2" for DSA where "$HOME" is the home directory for the user as who you want to log in on the remote machine. After this step, assuming the other configuration is fine, an "$ ssh -l remote_user_name remote_host_name" should be about enough to log in to the remote machine. A piece of advice: if you want security, read all the manual documentation you have about ssh. Good luck, -- Pavel M. Penev -- 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 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))"?). 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
Re: Debian audititing tool?
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))"?). 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]
