Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Christopher Head]

On January 16, 2018 6:24:31 AM PST, Michael Schwingen  
wrote:
>Limiting file access to a list of configured directories should be
>enough.
>However, if you really need this, you can get that now by running
>OpenOCD in firejail.

Firejail looks like it might help. I’m not sure file access or local command 
execution is the only issue here, though. OpenOCD is a tool for embedded system 
development. Depending on the nature of said system, granting an attacker 
access to the target probably allows them to at best create a 3.3-to-ground 
short on a GPIO and perhaps damage the I/O driver, up to at worst set your desk 
on fire. I’m not totally convinced that allowing an attacker to do *anything* 
with OpenOCD is safe.

-- 
Christopher Head
-- 
Christopher Head

signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Michael Schwingen]

On 15.01.2018 03:26, Christopher Head wrote:
> On January 14, 2018 12:37:53 PM PST, Michael Schwingen 
>  wrote:
>> How about a safe mode that disallows "dangerous" commands (eg. those
>> that call external programs)? This would be a bit like "-dSAFER" on
>> ghostscript, which disallows certain commands when processing untrusted
>> input.
> That sounds awfully difficult to get right. After all, if I want to steal 
> your top secret document, all I need available to me is PROGRAM (to put a 
> copy of said document into the microcontroller) followed by MDW (to read it 
> back).
Limiting file access to a list of configured directories should be enough.
However, if you really need this, you can get that now by running
OpenOCD in firejail.

cu
Michael


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Christopher Head]

On January 14, 2018 12:37:53 PM PST, Michael Schwingen  
wrote:
>How about a safe mode that disallows "dangerous" commands (eg. those
>that call external programs)? This would be a bit like "-dSAFER" on
>ghostscript, which disallows certain commands when processing untrusted
>input.

That sounds awfully difficult to get right. After all, if I want to steal your 
top secret document, all I need available to me is PROGRAM (to put a copy of 
said document into the microcontroller) followed by MDW (to read it back).

-- 
Christopher Head

signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Michael Schwingen]

On 14.01.2018 20:38, Tomas Vanek via OpenOCD-devel wrote:
> On 14.01.2018 20:06, Tomas Vanek via OpenOCD-devel wrote:
>> On 14.01.2018 18:01, Christopher Head wrote:
>>> none of the above attacks would work if you had to, say, type a
>>> password before OpenOCD would accept your Telnet (or GDB, or TCL, or
>>> …) session.
>> If OpenOCD would require a password it also needs a safe channel to
>> transfer it. Drop telnet and use a ssh library instead?
>>
> And one more concern: gdb protocol has remote command so port  is
> as vulnerable as the telnet port. How do you want to secure it?
How about a safe mode that disallows "dangerous" commands (eg. those
that call external programs)? This would be a bit like "-dSAFER" on
ghostscript, which disallows certain commands when processing untrusted
input.

A new gdb remote command (eg. "login") might be used to transport the
password - the user can put it in his gdb scripts, and the attacker will
be blocked from doing bad things (at least to me, an attacker messing
with my debug session is not a big problem as long as he can't get
access to my machine or my data).

cu
Michael



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Paul Fertser]

Hi Josef,

On Sun, Jan 14, 2018 at 08:28:51PM +, Josef Gajdusek wrote:
> Related: Some recursors have "DNS rebinding protection", which should filter 
> this.
> My OpenWRT router seems to have this enabled, the Google 8.8.8.8 nameservers 
> do not.

Not that it's really important, but the project name is OpenWrt.

> Overall, the state of application-level isolation on desktop operating systems
> seems to be stuck in 1990 for some reason.

Qubes OS seems to be the most usable general purpose solution
currently.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Josef Gajdusek]

January 14, 2018 6:03 PM, "Christopher Head"  wrote:

> I don’t think that just blocking HTTP verbs is good enough. Let’s consider 
> some more examples.
> 
> Example 1: Alice spends lots of time on IRC. She’s also interested in 
> embedded systems, so she runs
> OpenOCD. Bob has a file to send her, so they start an IRC CTCP session. Bob 
> configures his IRC
> client to claim his IP address is 127.0.0.1 and the CTCP listener is on port 
> . Alice’s IRC
> client sends some crud to her OpenOCD, which might include text that Bob can 
> partially control.
> 
> Example 2: Alice runs an FTP server. Bob connects to it and uploads a file 
> containing some OpenOCD
> script. He then issues an FTP GET command, in active mode, specifying the 
> data channel to be at
> 127.0.0.1:. Alice’s FTP server connects to her OpenOCD’s Telnet port and 
> dumps Bob’s uploaded
> file straight into it.
> 
> Example 3: Alice does a lot of online gaming. Bob sends an invitation to a 
> new server he found. The
> invitation contains a hostname, port number, and invitation key used to 
> authenticate to the server.
> The game shows a popup with invitation details: host example.com, port . 
> The invitation key
> isn’t shown, because it’s supposed to be just some random bytes. Unknown to 
> Alice, Bob went to
> Godaddy yesterday and registered example.com, and its DNS server now resolves 
> example.com to
> 127.0.0.1. Also unknown to Alice, the invitation key isn’t as random as it 
> ought to be: it’s
> actually some OpenOCD commands
> 

Related: Some recursors have "DNS rebinding protection", which should filter 
this.
My OpenWRT router seems to have this enabled, the Google 8.8.8.8 nameservers do 
not.

> Example 4: Alice is using her Web browser. She clicks on a link, an act that 
> should be harmless. It
> points at 
> ftp://some-openocd-script:some-password@localhost:/some/filename. Or a 
> similar Gopher
> URL. Or a Websockets URL. Or any number of other protocols that Web browsers 
> also understand.
> 

lol, this actually works with gopher in elinks.

> Example 5: Alice and Bob live together. To save space or money, they share a 
> single desktop for
> serious computing work. They practice good computing hygiene: their home 
> directories are mode 0700,
> they have good passwords, they always log out when done, and they keep their 
> machine up to date
> with security patches. They sometimes need access to their personal files 
> while they’re out, so
> they set up SSH access from their phones. Alice, sitting at the desktop, runs 
> OpenOCD. Bob, sitting
> at the coffee shop, runs ssh -L:localhost: homebox.
> 
> I’m not claiming to have tested all of the above. I’m not claiming that all 
> of the above are
> actually workable attacks. Rather, they’re a few examples I wrote up while 
> waiting for a bus. If I
> can think of these, no doubt a dedicated attacker can think of many more, and 
> some of them will
> work even if not all of them do. In my opinion, blindly trusting localhost is 
> the fundamental
> problem here: none of the above attacks would work if you had to, say, type a 
> password before
> OpenOCD would accept your Telnet (or GDB, or TCL, or …) session.

A slightly better option: provide a simple "client" binary, which connects
to a UNIX socket/Windows named pipe or whatewer is actually supposed to serve 
for
communication between applications on the same computer.

netcat-openbsd even has -U option for connecting to an unix socket.

Note: Unix sockets can apparently be forwarded over SSH natively, without
fumbling with socat - https://lwn.net/Articles/609321/

As these are annoyingly platform dependent, another alternative is keeping
TCP and using a "cookie" file, such as Tor does -
https://stem.torproject.org/faq.html#i-m-using-cookie-authentication
The client binary could load this file transparently, from some known location.

> -- 
> Christopher Head
> -- 
> Christopher Head
> ___
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel

Overall, the state of application-level isolation on desktop operating systems
seems to be stuck in 1990 for some reason.

Josef Gajdusek

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Michael Schwingen]

On 14.01.2018 20:06, Tomas Vanek via OpenOCD-devel wrote:
> On 14.01.2018 18:01, Christopher Head wrote:
>> none of the above attacks would work if you had to, say, type a
>> password before OpenOCD would accept your Telnet (or GDB, or TCL, or
>> …) session.
> If OpenOCD would require a password it also needs a safe channel to
> transfer it. Drop telnet and use a ssh library instead?
It would be enough if a fixed password was set on the OpenOCD
commandline or in some config file - all scenarios so far assume that
the attacker does not already have access to the local filesystem, so he
would not know the password - while the user who started OpenOCD would.

cu
Michael



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Christopher Head]

On January 14, 2018 11:06:04 AM PST, Tomas Vanek via OpenOCD-devel 
 wrote:
>If OpenOCD would require a password it also needs a safe channel to 
>transfer it. Drop telnet and use a ssh library instead?

Randomly generate it a print it to stdout at startup? Put it in the config 
file? Neither of those is vulnerable. Neither one handles GDB though. SSH 
doesn’t really solve the problem, actually: it would prevent packet sniffing 
(which can’t happen on localhost anyway, at least not without elevated 
privileges) but you would still need either a password or a key to authenticate 
the remote peer.

I was really just trying to point out how this is a big problem which may be 
impractical to solve (especially the GDB remote, since the protocol is fixed). 
Would it be possible to replace all transports with named pipes? They can all 
work over pipes, but only stdio AFAIK, and there are too many interfaces to 
handle them all that way (especially with multiple taps).

-- 
Christopher Head

signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Tomas Vanek via OpenOCD-devel]

On 14.01.2018 20:06, Tomas Vanek via OpenOCD-devel wrote:

On 14.01.2018 18:01, Christopher Head wrote:
none of the above attacks would work if you had to, say, type a 
password before OpenOCD would accept your Telnet (or GDB, or TCL, or 
…) session.
If OpenOCD would require a password it also needs a safe channel to 
transfer it. Drop telnet and use a ssh library instead?


And one more concern: gdb protocol has remote command so port  is as 
vulnerable as the telnet port. How do you want to secure it?


Tom

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Tomas Vanek via OpenOCD-devel]

On 14.01.2018 18:01, Christopher Head wrote:

none of the above attacks would work if you had to, say, type a password before 
OpenOCD would accept your Telnet (or GDB, or TCL, or …) session.
If OpenOCD would require a password it also needs a safe channel to 
transfer it. Drop telnet and use a ssh library instead?


Tom

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Christopher Head]

I don’t think that just blocking HTTP verbs is good enough. Let’s consider some 
more examples.

Example 1: Alice spends lots of time on IRC. She’s also interested in embedded 
systems, so she runs OpenOCD. Bob has a file to send her, so they start an IRC 
CTCP session. Bob configures his IRC client to claim his IP address is 
127.0.0.1 and the CTCP listener is on port . Alice’s IRC client sends some 
crud to her OpenOCD, which might include text that Bob can partially control.

Example 2: Alice runs an FTP server. Bob connects to it and uploads a file 
containing some OpenOCD script. He then issues an FTP GET command, in active 
mode, specifying the data channel to be at 127.0.0.1:. Alice’s FTP server 
connects to her OpenOCD’s Telnet port and dumps Bob’s uploaded file straight 
into it.

Example 3: Alice does a lot of online gaming. Bob sends an invitation to a new 
server he found. The invitation contains a hostname, port number, and 
invitation key used to authenticate to the server. The game shows a popup with 
invitation details: host example.com, port . The invitation key isn’t 
shown, because it’s supposed to be just some random bytes. Unknown to Alice, 
Bob went to Godaddy yesterday and registered example.com, and its DNS server 
now resolves example.com to 127.0.0.1. Also unknown to Alice, the invitation 
key isn’t as random as it ought to be: it’s actually some OpenOCD commands

Example 4: Alice is using her Web browser. She clicks on a link, an act that 
should be harmless. It points at 
ftp://some-openocd-script:some-password@localhost:/some/filename. Or a 
similar Gopher URL. Or a Websockets URL. Or any number of other protocols that 
Web browsers also understand.

Example 5: Alice and Bob live together. To save space or money, they share a 
single desktop for serious computing work. They practice good computing 
hygiene: their home directories are mode 0700, they have good passwords, they 
always log out when done, and they keep their machine up to date with security 
patches. They sometimes need access to their personal files while they’re out, 
so they set up SSH access from their phones. Alice, sitting at the desktop, 
runs OpenOCD. Bob, sitting at the coffee shop, runs ssh -L:localhost: 
homebox.

I’m not claiming to have tested all of the above. I’m not claiming that all of 
the above are actually workable attacks. Rather, they’re a few examples I wrote 
up while waiting for a bus. If I can think of these, no doubt a dedicated 
attacker can think of many more, and some of them will work even if not all of 
them do. In my opinion, blindly trusting localhost is the fundamental problem 
here: none of the above attacks would work if you had to, say, type a password 
before OpenOCD would accept your Telnet (or GDB, or TCL, or …) session.
-- 
Christopher Head
-- 
Christopher Head

signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Andreas Fritiofson]

On Fri, Jan 12, 2018 at 10:28 PM, Josef Gajdusek  wrote:

>
> Suggested fix: https://github.com/antirez/redis/blob/
> 8075572207b5aebb1385c4f233f5302544439325/src/networking.c#L1758
>
>
I ported the Redis fix to OpenOCD, please review:
http://openocd.zylin.com/4335

Although honestly I think this is completely a browser security issue which
just shows how horrible the Web security model is.

/Andreas
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Josef Gajdusek]

January 12, 2018 11:07 PM, "Paul Fertser"  wrote:

> Hey Josef,
> 
> Nice one, thank you. Good thing I'm running noscript.
> 

Note that you technically don't need to use javascript to make the request - 
see https://bouk.co/blog/hacking-developers/ for a plain -based version.

> BTW, what is the real and proper fix for this kind of attacks? To me
> it sounds like the web-browser itself shouldn't be able to send any
> requests with a JS loaded from one website to other hosts.
> 

I don't think there is any application-side "nice" fix.

A simple heuristic on the browser side such as "don't allow websites from 
not-localhost to make
request to anywhere localhost" would surely help in most (but not all) cases,
I am not sure why modern browsers don't implement that.

(see this related twitter thread 
https://twitter.com/taviso/status/951537891372556288 )

There are also the "unsafe" (irc, smtp...) ports which modern browsers refuse 
to connect to.


> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting

[Paul Fertser]

Hey Josef,

Nice one, thank you. Good thing I'm running noscript.

BTW, what is the real and proper fix for this kind of attacks? To me
it sounds like the web-browser itself shouldn't be able to send any
requests with a JS loaded from one website to other hosts.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel