Re: Shadow TCP stacks
On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: 2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: I still don't see the benefit though but do see added complexity or more code to audit. Reducing DDOS against a visible SSH service maybe? Reduce password attempts on your logs allowing them to go after targets that might actually use passwords (port change also works there, I find)? The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something.
Re: sudo bad practice or inconsistency?
Alessandro DE LAURENZIS just22.adl at gmail.com writes: (line-wrapped because of GMane) #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ xfe /dev/null sleep 1' ^^ Note that this will not work on OpenBSD anyway; even mksh, which does implement this bashism, will not parse this as expected in POSIX mode. So, besides the changes the others already pointed out: #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ xfe /dev/null 21 sleep 1' bye, //mirabilos
Re: Shadow TCP stacks
2014-10-17 10:24 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something. That's not the scenario here. The scenario is defense against port scans. You look like a fool who hasn't read the original paper.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:56:48PM +0200, Martin Schr??der wrote: 2014-10-17 10:24 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something. That's not the scenario here. The scenario is defense against port scans. You look like a fool who hasn't read the original paper. Quoting the OP a few emails back: The idea is that the existence of this entire 'ultranet' is undetectable by even someone snooping all national traffic. So a TCP port 80 connection looks to the snooper _exactly_ like an HTTP connection handshake. Only the ISN and the source address mark the connection as 'ultra' and take it into a back room where it connects to the real network. Just sayin'.
Fix xfe (Was: sudo bad practice or inconsistency?)
From: Thorsten Glaser t...@mirbsd.org Date: Fri, Oct 17, 2014 at 10:44 AM Subject: Re: sudo bad practice or inconsistency? To: misc@openbsd.org Alessandro DE LAURENZIS just22.adl at gmail.com writes: (line-wrapped because of GMane) #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ xfe /dev/null sleep 1' ^^ Note that this will not work on OpenBSD anyway; even mksh, which does implement this bashism, will not parse this as expected in POSIX mode. So, besides the changes the others already pointed out: #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ xfe /dev/null 21 sleep 1' Brian et al., ok for the diff below? Index: Makefile === RCS file: /cvs/ports/x11/xfe/Makefile,v retrieving revision 1.33 diff -u -p -u -p -r1.33 Makefile --- Makefile25 Nov 2013 18:39:02 - 1.33 +++ Makefile17 Oct 2014 11:45:34 - @@ -3,7 +3,7 @@ COMMENT= MS-Explorer like file manager for X DISTNAME= xfe-1.37 -REVISION= 0 +REVISION= 1 CATEGORIES=x11 HOMEPAGE= http://roland65.free.fr/xfe/ Index: patches/patch-src_xfedefs_h === RCS file: patches/patch-src_xfedefs_h diff -N patches/patch-src_xfedefs_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_xfedefs_h 17 Oct 2014 11:45:35 - @@ -0,0 +1,20 @@ +$OpenBSD$ + +Unbreak launching Xfe as root with sudo or su + +--- src/xfedefs.h.orig Fri Oct 17 13:41:26 2014 src/xfedefs.h Fri Oct 17 13:43:44 2014 +@@ -157,11 +157,11 @@ + + // Command to launch Xfe as root with sudo or su, using Xvt as a terminal + #ifndef SUDOCMD +-#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe /dev/null sleep 1' ++#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe /dev/null 21 sleep 1' + #endif + + #ifndef SUCMD +-#define SUCMD -fn 7x14 -geometry 60x4 -e su -c 'nohup xfe /dev/null sleep 1' ++#define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 21 sleep 1' + #endif + + // Tooltips setup time and duration
relayd question - from the man page
Hi folks,
The manpage for relayd.conf has this basic construct in it a couple of times :
table service { 192.168.1.1, 192.168.1.2, 192.168.2.3 }
table fallback disable { 10.1.5.1 retry 2 }
redirect www {
listen on www.example.com port 80
forward to service check http / code 200
forward to fallback check http / code 200
}
And also has this to say about the disable attribute.
disable
The redirection is initially disabled. It can be later enabled
through relayctl(8).
What I don't understand from the given examples is how fallback
above is getting re-enabled. It starts out with the table disabled -
I get that. But then within the redirect we are basically saying
(correct me if I am wrong) always use service unless it is not
availble, in which case use fallback
But I don't see anywhere that fallback was re-enabled so how can it
be used? And I search through the manpage and don't see any mention
of this. Does it automatically get re-enabled within the redirect -
forward? And if that is the case, what was the point of starting it
disabled in the first place?
thanks,
-Alan
--
Don't eat anything you've ever seen advertised on TV
- Michael Pollan, author of In Defense of Food
GCC Undefined Behavior Sanitizer – ubsan
Hallo, Undefined behavior is a concept known especially in the C and C++ languages which means that the semantics of certain operations is undefined and the compiler presumes that such operations never happen. For instance, using non-static variable before it has been initialized is undefined. If an undefined behavior occurs, the compiler is free to do anything. The application can produce wrong results, crash, or print the complete text of Proustâs oeuvre. https://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Is it useful for OpenBSD?
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com wrote: On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: 2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something. They don't have any clue which traffic to analyze though, so this traffic is a needle in a haystack. Also, the VPN could be tunneled over HTTP if necessary. Ian
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 9:13 AM, Ian Grant ian.a.n.gr...@googlemail.com wrote: On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com wrote: On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: 2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something. They don't have any clue which traffic to analyze though, so this traffic is a needle in a haystack. Also, the VPN could be tunneled over HTTP if necessary. Ian Right. Because the NSA/GHCQ don't have the resources to accomplish such a goal.
httpd, php, and httpd.conf in 5.6
All, Installed 5.6-current last night and saw that the new httpd daemon will be using the config file /etc/httpd.conf (which looks like it needs to be created by hand, fine). At the risk of sounding like a knucklehead, are there good examples of how to hook php to the new daemon? (Or for that matter a complete starter httpd.conf to use as reference material?) I've looked through man httpd.conf From reading thus far, it looks like the process will be similar to the process of connecting nginx with php, I'd just love to see some examples if they exist to minimize the learning curve. As always, thanks, Kevin
Re: httpd, php, and httpd.conf in 5.6
On Fri, Oct 17, 2014 at 09:45:41AM -0700, Kevin wrote: All, Installed 5.6-current last night and saw that the new httpd daemon will be using the config file /etc/httpd.conf (which looks like it needs to be created by hand, fine). At the risk of sounding like a knucklehead, are there good examples of how to hook php to the new daemon? (Or for that matter a complete starter httpd.conf to use as reference material?) I've looked through man httpd.conf From reading thus far, it looks like the process will be similar to the process of connecting nginx with php, I'd just love to see some examples if they exist to minimize the learning curve. As always, thanks, Kevin /etc/examples/httpd.conf --
Re: httpd, php, and httpd.conf in 5.6
On Fri, Oct 17, 2014 at 9:51 AM, Zé Loff zel...@zeloff.org wrote: Installed 5.6-current last night and saw that the new httpd daemon will be using the config file /etc/httpd.conf (which looks like it needs to be created by hand, fine). At the risk of sounding like a knucklehead, are there good examples of how to hook php to the new daemon? (Or for that matter a complete starter httpd.conf to use as reference material?) I've looked through man httpd.conf From reading thus far, it looks like the process will be similar to the process of connecting nginx with php, I'd just love to see some examples if they exist to minimize the learning curve. /etc/examples/httpd.conf Thanks for the speedy replies everyone. :-)
Re: Fix xfe (Was: sudo bad practice or inconsistency?)
On Fri, Oct 17, 2014 at 05:51:08AM -0600, David Coppa wrote: From: Thorsten Glaser t...@mirbsd.org Date: Fri, Oct 17, 2014 at 10:44 AM Subject: Re: sudo bad practice or inconsistency? To: misc@openbsd.org Alessandro DE LAURENZIS just22.adl at gmail.com writes: (line-wrapped because of GMane) #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ xfe /dev/null sleep 1' ^^ Note that this will not work on OpenBSD anyway; even mksh, which does implement this bashism, will not parse this as expected in POSIX mode. So, besides the changes the others already pointed out: #define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ xfe /dev/null 21 sleep 1' As I read the man page for su it is the target's login shell that is invoked, and it need not always be /bin/sh - it can be changed. Therefore I suspect that you want -s /bin/sh between su and root. Brian et al., ok for the diff below? Index: Makefile === RCS file: /cvs/ports/x11/xfe/Makefile,v retrieving revision 1.33 diff -u -p -u -p -r1.33 Makefile --- Makefile 25 Nov 2013 18:39:02 - 1.33 +++ Makefile 17 Oct 2014 11:45:34 - @@ -3,7 +3,7 @@ COMMENT= MS-Explorer like file manager for X DISTNAME=xfe-1.37 -REVISION=0 +REVISION=1 CATEGORIES= x11 HOMEPAGE=http://roland65.free.fr/xfe/ Index: patches/patch-src_xfedefs_h === RCS file: patches/patch-src_xfedefs_h diff -N patches/patch-src_xfedefs_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_xfedefs_h 17 Oct 2014 11:45:35 - @@ -0,0 +1,20 @@ +$OpenBSD$ + +Unbreak launching Xfe as root with sudo or su + +--- src/xfedefs.h.orig Fri Oct 17 13:41:26 2014 src/xfedefs.hFri Oct 17 13:43:44 2014 +@@ -157,11 +157,11 @@ + + // Command to launch Xfe as root with sudo or su, using Xvt as a terminal + #ifndef SUDOCMD +-#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe /dev/null sleep 1' ++#define SUDOCMD -fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe /dev/null 21 sleep 1' + #endif + + #ifndef SUCMD +-#define SUCMD -fn 7x14 -geometry 60x4 -e su -c 'nohup xfe /dev/null sleep 1' ++#define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 21 sleep 1' + #endif + + // Tooltips setup time and duration -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:13:55PM -0400, Ian Grant wrote: On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com wrote: On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: 2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something. They don't have any clue which traffic to analyze though, so this traffic is a needle in a haystack. Well, if, as Herr Schroeder seems to be implying, this is used to avoid port scans, I'd look for traffic to/from address:port which don't show up on scans. Also, the VPN could be tunneled over HTTP if necessary. I know of at least one company which sells a product which doesn't just read headers, but classifies traffic based upon behavior, e.g., small request receives large response - bulk transfer, or series of tiny packets which receive a single, larger response - interactive session. I assume nation-states have developed similar capabilities. The ability to use statistical methods to eavesdrop on encrypted SIP sessions comes to mind as an example of traffic analysis as a tool to defeat adversaries who are attempting to secure their communications.
Re: Shadow TCP stacks
2014-10-17 20:49 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: Well, if, as Herr Schroeder seems to be implying, this is used to avoid port scans, I'd look for traffic to/from address:port which don't show up on scans. That's certainly possible but more expensive than find all ssh servers. Best Martin
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert bret.lamb...@gmail.com wrote: Well, if, as Herr Schroeder seems to be implying, this is used to avoid port scans, I'd look for traffic to/from address:port which don't show up on scans. That's why I want to hide it behind an ordinary service. Also, the VPN could be tunneled over HTTP if necessary. I know of at least one company which sells a product which doesn't just read headers, but classifies traffic based upon behavior, e.g., small request receives large response - bulk transfer, or series of tiny packets which receive a single, larger response - interactive session. I assume nation-states have developed similar capabilities. That's fine. But they have to analyze all the traffic. This is a needle in a haystack. The ability to use statistical methods to eavesdrop on encrypted SIP sessions comes to mind as an example of traffic analysis as a tool to defeat adversaries who are attempting to secure their communications. Again, a needle in a haystack. Please read the OP before refuting stuff on the list. If you want to argue, and you aren't sure of your argument, e-mail me off the list. Otherwise it just adds to the general level of confusion, which is already higher than I'd expected on this list. Thanks, Ian
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 02:59:26PM -0400, Ian Grant wrote: On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert bret.lamb...@gmail.com wrote: Well, if, as Herr Schroeder seems to be implying, this is used to avoid port scans, I'd look for traffic to/from address:port which don't show up on scans. That's why I want to hide it behind an ordinary service. The point being, Herr Schroeder appears to be a man who would become one of your users, and has apparently missed that step. A manual that includes an advisory to do so would likely be a good idea. Also, the VPN could be tunneled over HTTP if necessary. I know of at least one company which sells a product which doesn't just read headers, but classifies traffic based upon behavior, e.g., small request receives large response - bulk transfer, or series of tiny packets which receive a single, larger response - interactive session. I assume nation-states have developed similar capabilities. That's fine. But they have to analyze all the traffic. This is a needle in a haystack. It's a good thing we don't know any nation-states that analyze all the traffic, then. That would probably be bad. The ability to use statistical methods to eavesdrop on encrypted SIP sessions comes to mind as an example of traffic analysis as a tool to defeat adversaries who are attempting to secure their communications. Again, a needle in a haystack. Assuming that your adversary is going into this blind, and hasn't been given a list of interesting targets that includes your systems. States also have access to human intelligence as well. Please read the OP before refuting stuff on the list. If you want to argue, and you aren't sure of your argument, e-mail me off the list. Otherwise it just adds to the general level of confusion, which is already higher than I'd expected on this list. Quoting the original email you sent: If anyone here has a better idea, or any other useful advice (even if it's this has already been done! or It won't work, but please explain exactly why.) or pointers I'm not attempting to refute the validity of what you're attempting, I'm pointing out things that probably should be taken into consideration during implementation/deployment, which I think falls under the heading of useful advice. Whether or not it's useful is a judgement left to the reader.
looking for coding hints with ptrace(2)
I'm trying to read the stack of another process that has the same user
credentials. Here is my program, I am stuck with this, it doesn't work
for me. Printing 0's is rewrapped to '.' and you should use this program
with hexdump like so: ./memtest [pid] | hexdump -C | less
Sometimes I get a bit of the stack but it seems random, dunno what the
deal is.
#include sys/types.h
#include sys/ptrace.h
#include machine/vmparam.h
#include machine/reg.h
#include stdio.h
#include stdlib.h
#include string.h
#include signal.h
#include unistd.h
int
main(int argc, char *argv[])
{
int64_t stackend = USRSTACK;
int64_t offset;
int64_t memsize;
char page[4096];
int pid, i;
size_t len;
int status;
char *p;
struct ptrace_io_desc ptid;
struct reg myreg;
if (argc 2) {
perror(args);
exit(1);
}
fprintf(stderr, stackend = %llx\n, stackend);
pid = atoi(argv[1]);
if (ptrace(PT_ATTACH, pid, NULL, 0) 0) {
perror(ptrace);
exit(1);
}
waitpid(pid, NULL, 0);
if (ptrace(PT_GETREGS, pid, (caddr_t)myreg, sizeof(myreg)) 0) {
perror(ptrace getregs);
exit(1);
}
offset = myreg.r_rsp;
fprintf(stderr, bottom of stack = %llx\n, offset);
memsize = stackend - offset;
p = calloc(1, memsize);
if (p == NULL) {
perror(malloc);
exit(1);
}
fprintf(stderr, memsize = %llx\n, memsize);
memset(ptid, 0, sizeof(ptid));
ptid.piod_op = PIOD_READ_I;
ptid.piod_offs = (void*)offset;
ptid.piod_addr = (void*)p;
ptid.piod_len = memsize;
status = ptrace(PT_IO, pid, (caddr_t)ptid, sizeof(ptid));
for (i = 0; i ptid.piod_len; i++) {
printf(%c, ((p[i] != 0) ? p[i] : '.'));
}
status = ptrace(PT_DETACH, pid, NULL, 0);
if (status 0) {
perror(ptrace detach);
exit(1);
}
exit(0);
}
Thanks for any hints,
-peter
Re: looking for coding hints with ptrace(2)
I'm trying to read the stack of another process that has the same user credentials. Here is my program, I am stuck with this, it doesn't work for me. Printing 0's is rewrapped to '.' and you should use this program with hexdump like so: ./memtest [pid] | hexdump -C | less Sometimes I get a bit of the stack but it seems random, dunno what the deal is. In OpenBSD, each process has the same 'stack space' (a large region), but actual area in use is biased randomly up to 256K or so. % sysctl kern.stackgap_random kern.stackgap_random=262144
Re: LibreSSL 2.1.1 released.
On Thu, Oct 16, 2014 at 9:15 AM, Bob Beck b...@openbsd.org wrote: We have released LibreSSL 2.1.1- which should be arriving in the LIbreSSL directory of an OpenBSD mirror near you very soon. If I clone the GitHub repo from Bolivia, do I have to cut my eyeballs out or stand guilty of re-exporting munitions from the USA? Ian
Re: Fix xfe (Was: sudo bad practice or inconsistency?)
On Fri 17/10 17:39, Raimo Niskanen wrote: As I read the man page for su it is the target's login shell that is invoked, and it need not always be /bin/sh - it can be changed. Therefore I suspect that you want -s /bin/sh between su and root. I'm confused: just22@poseidon:[~] sudo su -s /bin/sh root -c date Sat Oct 18 07:21:40 CEST 2014 just22@poseidon:[~] su -s /bin/sh root -c date su: only the superuser may specify a login shell (this is really weird). Moreover, using the following: #define SUCMD -fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe /dev/null 21 sleep 1' xfe correctly opens the password's window, but the echo is active during typing... (the same doesn't happen when I use sudo). It's just me? -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: looking for coding hints with ptrace(2)
On 10/17/14 22:38, Theo de Raadt wrote: I'm trying to read the stack of another process that has the same user credentials. Here is my program, I am stuck with this, it doesn't work for me. Printing 0's is rewrapped to '.' and you should use this program with hexdump like so: ./memtest [pid] | hexdump -C | less Sometimes I get a bit of the stack but it seems random, dunno what the deal is. In OpenBSD, each process has the same 'stack space' (a large region), but actual area in use is biased randomly up to 256K or so. % sysctl kern.stackgap_random kern.stackgap_random=262144 Stackgap! That's awesome! Too bad I forgot about it. And like it wasted my time it'll waste attackers time. Let me share what I was able to do on another OS. I wrote a proof-of-concept that reads crypto keys out of a certain program's stack while the user is hitting saving the crypto to a file. I'm not going to name that program but what's important, and I learned this lesson from OpenBSD, is that that cryptokeys and passwords are zero'ed right after their use. So thanks for both the stackgap and zero'ing keys! That's simply brilliant and makes attackers life harder. Cheers, -peter
Re: looking for coding hints with ptrace(2)
On Fri, Oct 17, 2014 at 1:34 PM, Peter J. Philipp p...@centroid.eu wrote:
I'm trying to read the stack of another process that has the same user
credentials. Here is my program, I am stuck with this, it doesn't work
for me. Printing 0's is rewrapped to '.' and you should use this program
with hexdump like so: ./memtest [pid] | hexdump -C | less
Sometimes I get a bit of the stack but it seems random, dunno what the
deal is.
...
int
main(int argc, char *argv[])
{
int64_t stackend = USRSTACK;
int64_t offset;
So 'offset' is a variable in the stack of this process...
memset(ptid, 0, sizeof(ptid));
ptid.piod_op = PIOD_READ_I;
ptid.piod_offs = (void*)offset;
...and you're telling ptrace() to take the address of 'offset' in
_this_ process and read from that address in the _target_ process.
That's not what you want; the '' in that line should be removed.
After that, the program works for me.
status = ptrace(PT_IO, pid, (caddr_t)ptid, sizeof(ptid));
The 4th argument to ptrace(...PT_IO...) is ignored and doesn't need to
be the size of the ptid structure.
Finally, if a ptrace() call after the PT_ATTACH fails then you
probably want to jump to detaching instead of exiting while attached
(which will kill the target process).
Philip Guenther
