On Sat, Oct 14, 2017 at 1:15 AM, Luke Small wrote:
> I am not certain about Braille, but what I am sure of is there is no
> incremental process to guessing a 64 bit datum that changes every single
> execution.
I'll note that in OpenBSD, stack cookies are the size of a register, so
they're only
I am not certain about Braille, but what I am sure of is there is no
incremental process to guessing a 64 bit datum that changes every single
execution. I typically don't state a fact unless I am willing to die if I
am incorrect. At least
https://en.m.wikipedia.org/wiki/Blind_return_oriented_progra
On Sat, Oct 14, 2017 at 12:49 AM, Luke Small wrote:
> If that's true, then why has Theo been speaking of the brop problems,
> when they begin with an incremental canary discovery that becomes all but
> impossible to guess when it becomes a random 4 byte datum each time rather
> than a datum that
If that's true, then why has Theo been speaking of the brop problems, when
they begin with an incremental canary discovery that becomes all but
impossible to guess when it becomes a random 4 byte datum each time rather
than a datum that remains the same each restart?
Braille should already be imp
On Fri, Oct 13, 2017 at 11:54 PM, Philip Guenther
wrote:
> On Fri, Oct 13, 2017 at 11:43 PM, Luke Small wrote:
>
>> I am not versed in operating systems as well as you, but I would think
>> that stack and buffer canaries would differ from each execution.
>>
>
> I suggest you examine the source,
On Fri, Oct 13, 2017 at 11:43 PM, Luke Small wrote:
> I am not versed in operating systems as well as you, but I would think
> that stack and buffer canaries would differ from each execution.
>
I suggest you examine the source, OR BETTER, examine actual processes under
a debugger, where you will
I am not versed in operating systems as well as you, but I would think that
stack and buffer canaries would differ from each execution.
On Fri, Oct 13, 2017 at 9:51 PM, Luke Small wrote:
> Maybe more things should be randomized like the stack canaries. Is that a
> new idea?
OpenBSD randomize perhaps more than any other OS. Randomization comes up
often in discussions. If something isn't randomized that could be, it's
probably
> Maybe more things should be randomized like the stack canaries. Is that a
> new idea?
Time to orer a new keyboar.
Maybe more things should be randomized like the stack canaries. Is that a
new idea?
On Fri, Oct 13, 2017 at 11:34 PM Theo de Raadt wrote:
> > I read "hacking blind." Can you restart a daemon with another forked
> > process that's only job is to monitor a pipe or a waitpid()-like
> operation
> > a
> I read "hacking blind." Can you restart a daemon with another forked
> process that's only job is to monitor a pipe or a waitpid()-like operation
> and if the parent dies, it exec's to restart it, or even execs "rcctl
> restart ntpd"
>
> If the mitigations are successful at limiting execution to
I read "hacking blind." Can you restart a daemon with another forked
process that's only job is to monitor a pipe or a waitpid()-like operation
and if the parent dies, it exec's to restart it, or even execs "rcctl
restart ntpd"
If the mitigations are successful at limiting execution to let's say,
> OpenBSD also has plenty of redundancy service failover (CARP, relayd
> etc.) as do service providers. So one/more can take over whilst the
> failed are audited.
Uhm, in your dreams.
This is a conversation about simply restarting such failing services.
On Thu, 12 Oct 2017 20:38:42 -0600
> > Perhaps I'm mistaken, but it doesn't seem like there's a facility
> > for automatically restarting daemons after a crash or similar. Is
> > the idea just that daemons should be designed to not crash?
>
> Yes. Fail closed. It is the only secure thing to
Hi Aaron & misc@,
My take:
I favor a tool that gives me (the end-user) more power. OpenBSD folks
are 100% right to maintain a particular policy (no automatic restarts),
but I see no reason to enforce it by taking away options from the end
users.
(Furthermore, I see no reason to attack a tool or
On 10/13/17 05:01, Mihai Popescu wrote:
>> That's sensible, but if money or lives were on the line, I think It'd
>> be better to have a running but potentially vulnerable service.
>
> Not OpenBSD related, but I was truly amazed people like you still
> exist and still set up computers for others!
>
On Fri, 13 Oct 2017 12:01:58 +0300
Mihai Popescu wrote:
> [...]
>
> Not OpenBSD related, but I was truly amazed people like you still
> exist and still set up computers for others!
> For you curiosity about user case, I preffer such a service not to be
> started at all.
>
> Money(online bank
> That's sensible, but if money or lives were on the line, I think It'd
> be better to have a running but potentially vulnerable service.
Not OpenBSD related, but I was truly amazed people like you still
exist and still set up computers for others!
For you curiosity about user case, I preffer such
> That's sensible, but if money or lives were on the line, I think It'd
> be better to have a running but potentially vulnerable service. For my
> use case, this is completely acceptable, I'm just curious about the
> implications for others.
Then you can do that on your own, if it suits your use c
>If software has a bug, you want to fix it. You don't want to keep
running it.
That's sensible, but if money or lives were on the line, I think It'd
be better to have a running but potentially vulnerable service. For my
use case, this is completely acceptable, I'm just curious about the
implicati
> Perhaps I'm mistaken, but it doesn't seem like there's a facility for
> automatically restarting daemons after a crash or similar. Is the idea
> just that daemons should be designed to not crash?
Yes. Fail closed. It is the only secure thing to do.
> I'm familiar with 3rd party tools like dae
21 matches
Mail list logo
