Re: Portmap non-local set / unset attempt
Quoting Clint M. Sand [EMAIL PROTECTED]: On Thu, Sep 22, 2005 at 07:09:12PM -0600, Theo de Raadt wrote: People keep yammering this bullshit about Security is a process. Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this Security is a process mantra to protect themselves from looking bad. Security is a process is intended to mean 2 things. One is that the idea that you can set and forget anything and think it's somehow secure is a joke. To secure a network includes at a minimum, keeping up with vendor patches for example. Processes like patch management help keep systems secure. It does not say Security is ONLY a process. Secondly, it is meant to refute the moronic idea that some admins seem to have is that buying any product makes you secure. Prevelant is the idea for example that if you have a firewall then you are now secure. Or, I have Norton AntiVirus so now my PC is secured. No, no no. You are playing the same semantic games that avoid responsibility at the ENGINEERING and PRODUCT DEVELOPMENT STAGES. It's so very very Microsoft. Just like the air-conditioning technicians I keep firing because they can't read schematics and charts. Which is why I now know MORE about air-conditioners than most of the technicians who come here. The phrase, and everything you said, is all excuses for the vendors. It IS POSSIBLE to set something up and have it be secure and NOT TOUCH IT, because many people have OpenBSD machines running older releases running without any modification for YEARS now, RISK FREE, without having to update ANY THING. No, you can put an openbsd box up and leave it for years with root login enabled and password for a password. It takes more than correct code. It's correct code plus correct usage. I think the GOBBLES sshd exploit is proof enough that set and forget is not risk free. Security is everything you've ever said, plus a process. If it is secure, it doesn't need a process. So why would security be a process again? Because of the vendors making mistakes and fix it later? Jimmy Scott This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
Re: Portmap non-local set / unset attempt
On 2005-09-23 00:05:14 -0700, Wolfgang S. Rupprecht wrote: appreciable added risk. The only loose end is that sshd doesn't currently log the RSA/DSA key that is used to gain access. Ideally it Hu? Try LogLevel VERBOSE Best Martin -- http://www.tm.oneiros.de
Re: Portmap non-local set / unset attempt
[EMAIL PROTECTED] wrote: Security is everything you've ever said, plus a process. If it is secure, it doesn't need a process. So why would security be a process again? Because of the vendors making mistakes and fix it later? Jimmy Scott It is a process in the same way that making toast is a process. The purchase of a bread-crisping solution that is UL-certified to not set your house on fire is the contribution of the engineering and product development stages. In common usage, using this solution to toast your morning snack will produce crispy bread and will not produce a howling conflagration. However, note that it is still very much possible to ignite your domicile by soaking a rag in lighter fluid, stuffing it into the bread-toasting slot, and jamming the switch closed with a butter knife. For a less extreme example, it _may_ be possible to cause a fire by leaving a towel too near the toaster while it is operating, something which is easy to do and all too common. Having a morning snack and an un-burnt house at the same time, then, is contingent upon two things - possessing a toaster of adequate quality, and using it properly. You don't get to have the whole package without a) looking for a good toaster in the first place, and b) learning how to use it. Security operates similarly: one boner mistake on anybody's part - coder, engineer or administrator - and your security vaporizes _instantly_. Go read some of Bruce Schneier's screeds on the subject, they're informative. So yes, security most certainly _is_ partly a process, various opinions to the contrary notwithstanding. It is identical to the process of locking your doors and checking your windows before you go to bed at night, or of making sure that you're not stuffing a paper towel or a cardboard box top in your toaster in the morning before you've had coffee. You could call it habitual prudence, I suppose. Of course, computers being based on hard-core determinism and Boolean logic, a higher standard is possible. I note in passing that the security of every operating system in common use (including OpenBSD) is _unproven_ [1], with the possible exception of Coyotos. Asserting something that is unproven and which may actually be impossible to prove (X is more secure than Y) is not a good idea. In other words, don't toss shit at the vendors unless you can _prove_, from a chain of irrefutable deduction, that your proposed solution is more secure than theirs. (Something which is likely impossible, due to OpenBSD's design and the language in which it is written.) Hint: the manpower, brainpower, and computing power needed to accomplish this task _even if_ it is possible is probably going to exceed anything you're willing to marshal to that end. Theo is right about one thing, however: Bugs and security flaws arise from mistakes, every one of which is avoidable. There are no new classes of bugs or design flaws, essentially every one has been generally known of and understood for decades. It is only sloppy practices - dare I say it, bad processes - that permit these bugs to creep into various codebases and multiply. The cure for this problem is better processes. The easy cure is for these processes to entail continuous auditing (the OBSD solution). The harder cure is to work on establishing and maintaining a process that incorporates rigorous proof as a necessary component. We may not ever see that, but hey - it's nice to dream, isn't it? -- (c) 2005 Unscathed Haze via Central Plexus [EMAIL PROTECTED] I am Chaos. I am alive, and I tell you that you are Free. -Eris Big Brother is watching you. Learn to become Invisible. | Your message must be this wide to ride the Internet. | [1] Rigorous proof, that is. Anecdotal evidence does not establish proof of anything whatsoever.
RE: Re: Portmap non-local set / unset attempt
Making is a process. Toast is not a process. - --- Original Message --- - From: [EMAIL PROTECTED] To: misc@openbsd.org Sent: Fri, 23 Sep 2005 02:30:10 [EMAIL PROTECTED] wrote: Security is everything you've ever said, plus a process. If it is secure, it doesn't need a process. So why would security be a process again? Because of the vendors making mistakes and fix it later? Jimmy Scott It is a process in the same way that making toast is a process. The purchase of a bread-crisping solution that is UL-certified to not set your house on fire is the contribution of the engineering and product development stages. In common usage, using this solution to toast your morning snack will produce crispy bread and will not produce a howling conflagration. However, note that it is still very much possible to ignite your domicile by soaking a rag in lighter fluid, stuffing it into the bread-toasting slot, and jamming the switch closed with a butter knife. For a less extreme example, it _may_ be possible to cause a fire by leaving a towel too near the toaster while it is operating, something which is easy to do and all too common. Having a morning snack and an un-burnt house at the same time, then, is contingent upon two things - possessing a toaster of adequate quality, and using it properly. You don't get to have the whole package without a) looking for a good toaster in the first place, and b) learning how to use it. Security operates similarly: one boner mistake on anybody's part - coder, engineer or administrator - and your security vaporizes _instantly_. Go read some of Bruce Schneier's screeds on the subject, they're informative. So yes, security most certainly _is_ partly a process, various opinions to the contrary notwithstanding. It is identical to the process of locking your doors and checking your windows before you go to bed at night, or of making sure that you're not stuffing a paper towel or a cardboard box top in your toaster in the morning before you've had coffee. You could call it habitual prudence, I suppose. Of course, computers being based on hard-core determinism and Boolean logic, a higher standard is possible. I note in passing that the security of every operating system in common use (including OpenBSD) is _unproven_ [1], with the possible exception of Coyotos. Asserting something that is unproven and which may actually be impossible to prove (X is more secure than Y) is not a good idea. In other words, don't toss shit at the vendors unless you can _prove_, from a chain of irrefutable deduction, that your proposed solution is more secure than theirs. (Something which is likely impossible, due to OpenBSD's design and the language in which it is written.) Hint: the manpower, brainpower, and computing power needed to accomplish this task _even if_ it is possible is probably going to exceed anything you're willing to marshal to that end. Theo is right about one thing, however: Bugs and security flaws arise from mistakes, every one of which is avoidable. There are no new classes of bugs or design flaws, essentially every one has been generally known of and understood for decades. It is only sloppy practices - dare I say it, bad processes - that permit these bugs to creep into various codebases and multiply. The cure for this problem is better processes. The easy cure is for these processes to entail continuous auditing (the OBSD solution). The harder cure is to work on establishing and maintaining a process that incorporates rigorous proof as a necessary component. We may not ever see that, but hey - it's nice to dream, isn't it? -- (c) 2005 Unscathed Haze via Central Plexus [EMAIL PROTECTED] I am Chaos. I am alive, and I tell you that you are Free. -Eris Big Brother is watching you. Learn to become Invisible. | Your message must be this wide to ride the Internet. | [1] Rigorous proof, that is. Anecdotal evidence does not establish proof of anything whatsoever.
Re: Portmap non-local set / unset attempt
Martin SchrC6der [EMAIL PROTECTED] writes: On 2005-09-23 00:05:14 -0700, Wolfgang S. Rupprecht wrote: appreciable added risk. The only loose end is that sshd doesn't currently log the RSA/DSA key that is used to gain access. Ideally it Hu? Try LogLevel VERBOSE Your eloquent reply aside, setting the loglevel to versbose doesn't add proper key accounting to the sshd login record. What it does is add yet more clutter to /var/log/authlog by emitting quite a few more lines per login. Sshd's logs seem more like debug printfs, scattered willy-nilly around the code. The information one would expect from a security program is never gathered in one spot and output in a single audit line to see who logged in as what user. -wolfgang
Re: Portmap non-local set / unset attempt
I'm receiving the following messages from portmap when starting Legato Networker's nsrexecd. The nsrexecd I'm running is the Linux version under emulation: portmap[16083]: non-local unset attempt (might be from 127.0.0.1) portmap[16083]: non-local set attempt (might be from 127.0.0.1) The program (number 390113) does not successfully register with the portmapper: # rpcinfo -p localhost program vers proto port 102 tcp111 portmapper 102 udp111 portmapper Is this a security feature? Yes, most definately. Changes made years ago slightly changed the communications API between libc/rpc and the portmap daemon, to make it much harder to generate spoofed RPC mappings. An attacker would make such mappings point one RPC service at another RPC service, and with the right forwarding games you can get mis-interpretation by an end point reulting in some risks. Therefore our portmap sets up special 127.0.0.1 local bound sockets, and only accepts set/unset operations on those sockets. The *:111 sockets can still be used to make other requests, but not deal with binding establishment. The program you are using is linked against a RPC library that is using your external address to change the mappings, ie. perhaps your external IP address. That is the old legacy way that the Sun code used to do it, and it was a bug, and it is full of risk. It's astounding that other people have not fixed this yet, considering that I did the work on that nearly 10 years ago. revision 1.3 date: 1996/06/29 19:03:50; author: deraadt; state: Exp; lines: +135 -64 multiple receivers, port checking. testing help from bitblt People keep yammering this bullshit about Security is a process. Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this Security is a process mantra to protect themselves from looking bad. Is there a way to get nrsexecd to register with the portmapper? You cannot get a Linux binary to talk to our portmap, without modifying our portmap code to not have this security check. And that would be a shame. Sorry...
Re: Portmap non-local set / unset attempt
That's what I thought. I have no idea why Legato continues to use portmapper
at all. They've been telling me they're going to stop using it since at
least 1999.
I actually came up with a workaround that I think might expose a potential
issue in rpcinfo.
Since I couldn't get nsrexecd to automatically register with the portmapper,
I tried to register it manually using rpcinfo -s. An entry was added, but it
made the protocol number 2 instead of tcp (6), which is what I need.
# rpcinfo -s 390113 1 7937
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
3901131 2 7937
# rpcinfo -t localhost 390113
rpcinfo: RPC: Program not registered
program 390113 is not available
I looked and couldn't find any way to set the protocol to TCP (6). Looking
at the source for rpcinfo, I found the following:
if ((pmap_set(prog_num, version_num, PF_INET,
(u_short)port_num)) == 0) {
fprintf(stderr, rpcinfo: Could not set registration
for prog %s version %s port %s\n,
argv[0], argv[1], argv[2]);
exit(1);
}
Seems like rpcinfo will always set the protocol to the constant PF_INET,
which is actually AF_INET, which is actually 2.
In order to work around this, I created the following short program:
#include rpc/rpc.h
main()
{
pmap_set(390113, 1, 6, 7937);
}
Notice the 6 in the 3rd argument to pmap_set, rather than the constant
PF_INET (2).
After deleting the previous portmapper entry and running my little kludge, I
get the following:
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
3901131 tcp 7937
# rpcinfo -t localhost 390113
program 390113 version 1 ready and waiting
Which brings me to ask: Should an additional argument be added to rpcinfo -s
to specify a protocol, rather than forcing the constant PF_INET?
-Original Message-
From: Theo de Raadt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 22, 2005 1:02 PM
To: Michael Favinsky
Cc: 'misc@openbsd.org'
Subject: Re: Portmap non-local set / unset attempt
I'm receiving the following messages from portmap when starting Legato
Networker's nsrexecd. The nsrexecd I'm running is the Linux version
under
emulation:
portmap[16083]: non-local unset attempt (might be from 127.0.0.1)
portmap[16083]: non-local set attempt (might be from 127.0.0.1)
The program (number 390113) does not successfully register with the
portmapper:
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
Is this a security feature?
Yes, most definately.
Changes made years ago slightly changed the communications API between
libc/rpc and the portmap daemon, to make it much harder to generate spoofed
RPC mappings. An attacker would make such mappings point one RPC service at
another RPC service, and with the right forwarding games you can get
mis-interpretation by an end point reulting in some risks.
Therefore our portmap sets up special 127.0.0.1 local bound sockets, and
only accepts set/unset operations on those sockets. The *:111 sockets can
still be used to make other requests, but not deal with binding
establishment.
The program you are using is linked against a RPC library that is using your
external address to change the mappings, ie. perhaps your external IP
address. That is the old legacy way that the Sun code used to do it, and it
was a bug, and it is full of risk.
It's astounding that other people have not fixed this yet, considering that
I did the work on that nearly 10 years ago.
revision 1.3
date: 1996/06/29 19:03:50; author: deraadt; state: Exp; lines: +135 -64
multiple receivers, port checking. testing help from bitblt
People keep yammering this bullshit about Security is a process.
Bullshit! Lies! It's about paying attention to the frigging details when
they are right in front of your face. And it is very clear other vendors do
not pay attention to the details, considering the work I did here was talked
about all over BUGTRAQ back in that month. No wonder these vendors and
their blogboys have to have this Security is a process mantra to protect
themselves from looking bad.
Is there a way to get nrsexecd to register with the portmapper?
You cannot get a Linux binary to talk to our portmap, without modifying our
portmap code to not have this security check. And that would be a shame.
Sorry...
This message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient of this message you may not store, disclose, copy, forward,
distribute or use this message or its contents for any purpose. If you have
received this communication in error, please notify us immediately by return
e-mail and delete
Re: Portmap non-local set / unset attempt
On Thu, Sep 22, 2005 at 02:02:13PM -0600, Theo de Raadt wrote: snip People keep yammering this bullshit about Security is a process. Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this Security is a process mantra to protect themselves from looking bad. Security is a process is intended to mean 2 things. One is that the idea that you can set and forget anything and think it's somehow secure is a joke. To secure a network includes at a minimum, keeping up with vendor patches for example. Processes like patch management help keep systems secure. It does not say Security is ONLY a process. Secondly, it is meant to refute the moronic idea that some admins seem to have is that buying any product makes you secure. Prevelant is the idea for example that if you have a firewall then you are now secure. Or, I have Norton AntiVirus so now my PC is secured.
Re: Portmap non-local set / unset attempt
People keep yammering this bullshit about Security is a process. Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this Security is a process mantra to protect themselves from looking bad. Security is a process is intended to mean 2 things. One is that the idea that you can set and forget anything and think it's somehow secure is a joke. To secure a network includes at a minimum, keeping up with vendor patches for example. Processes like patch management help keep systems secure. It does not say Security is ONLY a process. Secondly, it is meant to refute the moronic idea that some admins seem to have is that buying any product makes you secure. Prevelant is the idea for example that if you have a firewall then you are now secure. Or, I have Norton AntiVirus so now my PC is secured. No, no no. You are playing the same semantic games that avoid responsibility at the ENGINEERING and PRODUCT DEVELOPMENT STAGES. It's so very very Microsoft. Just like the air-conditioning technicians I keep firing because they can't read schematics and charts. Which is why I now know MORE about air-conditioners than most of the technicians who come here. The phrase, and everything you said, is all excuses for the vendors. It IS POSSIBLE to set something up and have it be secure and NOT TOUCH IT, because many people have OpenBSD machines running older releases running without any modification for YEARS now, RISK FREE, without having to update ANY THING.
Re: Portmap non-local set / unset attempt
Which is why I now know MORE about air-conditioners than most of the technicians who come here. The phrase, and everything you said, is all excuses for the vendors. I bet that the air-conditoner technicians believe that Air-conditioner maintainance is a process. Which is why they can never do a proper job. It is a cop-out when they say it, it is a cop-out when a unix vendor says it, and it is a copout whenever ANYONE SAYS IT.
Re: Portmap non-local set / unset attempt
On Thu, Sep 22, 2005 at 07:09:12PM -0600, Theo de Raadt wrote: People keep yammering this bullshit about Security is a process. Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this Security is a process mantra to protect themselves from looking bad. Security is a process is intended to mean 2 things. One is that the idea that you can set and forget anything and think it's somehow secure is a joke. To secure a network includes at a minimum, keeping up with vendor patches for example. Processes like patch management help keep systems secure. It does not say Security is ONLY a process. Secondly, it is meant to refute the moronic idea that some admins seem to have is that buying any product makes you secure. Prevelant is the idea for example that if you have a firewall then you are now secure. Or, I have Norton AntiVirus so now my PC is secured. No, no no. You are playing the same semantic games that avoid responsibility at the ENGINEERING and PRODUCT DEVELOPMENT STAGES. It's so very very Microsoft. Just like the air-conditioning technicians I keep firing because they can't read schematics and charts. Which is why I now know MORE about air-conditioners than most of the technicians who come here. The phrase, and everything you said, is all excuses for the vendors. It IS POSSIBLE to set something up and have it be secure and NOT TOUCH IT, because many people have OpenBSD machines running older releases running without any modification for YEARS now, RISK FREE, without having to update ANY THING. No, you can put an openbsd box up and leave it for years with root login enabled and password for a password. It takes more than correct code. It's correct code plus correct usage. I think the GOBBLES sshd exploit is proof enough that set and forget is not risk free. Security is everything you've ever said, plus a process.
RE: Re: Portmap non-local set / unset attempt
Security is everything you've ever said, plus a process. No. security does not require the process. Attempted security (that doesn't quite work) requires a process. Like the difference between does work and should work.
