Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out of bounds access kills daemon #4003

Closed
kpcyrd opened this issue Jun 22, 2017 · 7 comments
Closed

Out of bounds access kills daemon #4003

kpcyrd opened this issue Jun 22, 2017 · 7 comments
Labels
kind/bug A bug in existing code (including security flaws) status/in-progress In progress

Comments

@kpcyrd
Copy link
Contributor

kpcyrd commented Jun 22, 2017

Version information:

The latest version of the release branch, currently 0.4.8. I've digged a bit into the code and it seems this is still the case on master.

Type:

Bug

Severity:

application panic, but probably not that critical

Description:

I've tried to write an api client for ipfs, while doing that I noticed my client is crashing the ipfs daemon. I was able to fix this issue and my client is now working correctly, but I spent some more time to reproduce the issue with a one-liner to verify the issue without compiling my application:

echo -ne "POST /api/v0/add?pin=true HTTP/1.1\r\nHost: 127.0.0.1:5001\r\nContent-Type: multipart/form-data; boundary=Pyw9xQLtiLPE6XcI\r\nContent-Length: 22\r\n\r\n\r\n--Pyw9xQLtiLPE6XcI\r\n" | nc -v 127.0.0.1 5001

This causes an out-of-bounds access on an empty list:

docker[18425]: panic: runtime error: index out of range
docker[18425]: goroutine 255211 [running]:
docker[18425]: github.com/ipfs/go-ipfs/core/coreunix.(*Adder).Finalize(0xc427bf26c0, 0xc420062020, 0x562d1ba4c7a0, 0xc420062020, 0xc420062001)
docker[18425]:         /go/src/github.com/ipfs/go-ipfs/core/coreunix/add.go:204 +0x315
docker[18425]: github.com/ipfs/go-ipfs/core/commands.glob..func6.1(0x562d1ba5c720, 0xc42c4ff350, 0xc42c4ff350, 0xc420287fd8)
docker[18425]:         /go/src/github.com/ipfs/go-ipfs/core/commands/add.go:254 +0x138
docker[18425]: github.com/ipfs/go-ipfs/core/commands.glob..func6.2(0xc42cd20420, 0xc4287dd040, 0x562d1ba610c0, 0xc42c1012c0, 0x562d1ba604a0, 0xc42941e380)
docker[18425]:         /go/src/github.com/ipfs/go-ipfs/core/commands/add.go:268 +0x7e
docker[18425]: created by github.com/ipfs/go-ipfs/core/commands.glob..func6
docker[18425]:         /go/src/github.com/ipfs/go-ipfs/core/commands/add.go:273 +0xa11
systemd[1]: go-ipfs.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

https://github.com/ipfs/go-ipfs/blob/b04cd7a68d55861850357c33a7c8fdaa4762f5ef/core/coreunix/add.go#L204

I hope this helps to resolve the underlying issue. :)

@Kubuxu Kubuxu added the kind/bug A bug in existing code (including security flaws) label Jun 22, 2017
@d34d10cc
Copy link
Contributor

d34d10cc commented Jul 8, 2017

There is no bug here. The thing that was crashing the daemon here is the fact that you used CRLF line endings rather than just LF.

To demonstrate, the command here is the same as yours just with all the \rs left out and it does not crash the daemon:

echo -ne "POST /api/v0/add?pin=true HTTP/1.1\nHost: 127.0.0.1:5001\nContent-Type: multipart/form-data; boundary=Pyw9xQLtiLPE6XcI\nContent-Length: 22\n\n\n--Pyw9xQLtiLPE6XcI\n" | nc -v 127.0.0.1 5001

@ghost
Copy link

ghost commented Jul 8, 2017

HTTP specifies that CRLF line endings should be used.

In any case, the daemon must not crash for any input, so there is a bug here.

@d34d10cc
Copy link
Contributor

d34d10cc commented Jul 8, 2017

Is there any chance for this to be assigned to me since I'm nearing in on the cause of the bug and I don't want to clash with anyone's work?

@ghost
Copy link

ghost commented Jul 8, 2017

Awesome, sure! :)

@Kubuxu Kubuxu added the status/in-progress In progress label Jul 8, 2017
@kpcyrd
Copy link
Contributor Author

kpcyrd commented Jul 8, 2017

@Quantomicus I've linked the bug in my original report:

https://github.com/ipfs/go-ipfs/blob/b04cd7a68d55861850357c33a7c8fdaa4762f5ef/core/coreunix/add.go#L204

It's assumed that children has >= 1 entries, but there's no check to assure this is actually the case.

@d34d10cc
Copy link
Contributor

d34d10cc commented Jul 9, 2017

The issue goes deeper than that. The issue is with parsing HTTP API requests involving multipart files. Since you only provide a boundary as the content, the parser gets confused and passes the broken data as a directory which leads to the code looking for children in the 'directory' down the callstack.

d34d10cc added a commit to d34d10cc/go-ipfs that referenced this issue Jul 9, 2017
Includes a general sanity check to skip further checks if user provided fewer arguments than minimum required and a specific check for corrupted data passed as file.

License: MIT
Signed-off-by: Mateja Milosevic <minima38123@gmail.com>
@toadkicker
Copy link

Getting similar error:

Daemon is ready
10:51:17.311 ERROR commands/h: a panic has occurred in the commands handler! handler.go:127
10:51:17.311 ERROR commands/h: runtime error: index out of range handler.go:128
goroutine 47955 [running]:
runtime/debug.Stack(0x21, 0xc423c4d5b0, 0x13af987)
	/home/whyrusleeping/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
	/home/whyrusleeping/go/src/runtime/debug/stack.go:16 +0x22
github.com/ipfs/go-ipfs/commands/http.internalHandler.ServeHTTP.func1()
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:130 +0x161
panic(0x1893780, 0x2009110)
	/home/whyrusleeping/go/src/runtime/panic.go:489 +0x2cf
github.com/ipfs/go-ipfs/core/commands.glob..func79(0x1f48f20, 0xc425dfb980, 0x1f48300, 0xc42374a380)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/core/commands/ping.go:90 +0x2c5
github.com/ipfs/go-ipfs/commands.(*Command).Call(0x2016860, 0x1f48f20, 0xc425dfb980, 0x0, 0x0)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/command.go:116 +0x1d5
github.com/ipfs/go-ipfs/commands/http.internalHandler.ServeHTTP(0x0, 0xc42024c4c0, 0x17, 0xc4202c3740, 0xc4200e21e0, 0x1af84d0, 0xc4201641c0, 0xc4202afc70, 0x2016860, 0xc4202c3650, ...)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:186 +0x6ca
github.com/ipfs/go-ipfs/commands/http.(*internalHandler).ServeHTTP(0xc4202dc780, 0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	<autogenerated>:4 +0x83
gx/ipfs/QmPG2kW5t27LuHgHnvhUwbHCNHAt2eUcb4gPHqofrESUdB/cors.(*Cors).Handler.func1(0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/gx/ipfs/QmPG2kW5t27LuHgHnvhUwbHCNHAt2eUcb4gPHqofrESUdB/cors/cors.go:188 +0xe9
net/http.HandlerFunc.ServeHTTP(0xc4200c7d00, 0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/server.go:1942 +0x44
github.com/ipfs/go-ipfs/commands/http.Handler.ServeHTTP(0x0, 0xc42024c4c0, 0x17, 0xc4202c3740, 0xc4200e21e0, 0x1af84d0, 0x0, 0xc4202afc70, 0x2016860, 0xc4202c3650, ...)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/github.com/ipfs/go-ipfs/commands/http/handler.go:119 +0x5e
github.com/ipfs/go-ipfs/commands/http.(*Handler).ServeHTTP(0xc420309f80, 0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	<autogenerated>:5 +0x8c
net/http.(*ServeMux).ServeHTTP(0xc4202c2c90, 0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/server.go:2238 +0x130
net/http.(Handler).ServeHTTP-fm(0x1f3e4a0, 0xc4202442b0, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/h2_bundle.go:4319 +0x4d
gx/ipfs/QmX3QZ5jHEPidwUrymXV1iSCSUhdGxj15sm2gP4jKMef7B/client_golang/prometheus.InstrumentHandlerFuncWithOpts.func1(0x1f3f7a0, 0xc425e5a540, 0xc4233bde00)
	/home/whyrusleeping/code/distributions/dists/go-ipfs/gopath/src/gx/ipfs/QmX3QZ5jHEPidwUrymXV1iSCSUhdGxj15sm2gP4jKMef7B/client_golang/prometheus/http.go:287 +0x26a
net/http.HandlerFunc.ServeHTTP(0xc4202dc6e0, 0x1f3f7a0, 0xc425e5a540, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/server.go:1942 +0x44
net/http.(*ServeMux).ServeHTTP(0xc4202c2c60, 0x1f3f7a0, 0xc425e5a540, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/server.go:2238 +0x130
net/http.serverHandler.ServeHTTP(0xc420171d90, 0x1f3f7a0, 0xc425e5a540, 0xc4233bde00)
	/home/whyrusleeping/go/src/net/http/server.go:2568 +0x92
net/http.(*conn).serve(0xc4260085a0, 0x1f404e0, 0xc42085e080)
	/home/whyrusleeping/go/src/net/http/server.go:1825 +0x612
created by net/http.(*Server).Serve
	/home/whyrusleeping/go/src/net/http/server.go:2668 +0x2ce

Stebalien added a commit that referenced this issue Jul 28, 2017
1. The echo needs a -e on some shells.
2. grep needs to exit after the first match as we're using HTTP/1.1 (the remote
side will not close the connection after sending the response).

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Jul 28, 2017
1. Use printf to reliably expand escape sequences by default.
2. grep needs to exit after the first match as we're using HTTP/1.1 (the remote
side will not close the connection after sending the response).

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Jul 28, 2017
1. Use printf to reliably expand escape sequences by default.
2. grep needs to exit after the first match as we're using HTTP/1.1 (the remote
side will not close the connection after sending the response).

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Jul 28, 2017
1. Use printf to reliably expand escape sequences by default.
2. grep needs to exit after the first match as we're using HTTP/1.1 (the remote
side will not close the connection after sending the response).

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Stebalien added a commit that referenced this issue Jul 29, 2017
1. Use printf to reliably expand escape sequences by default.
2. grep needs to exit after the first match as we're using HTTP/1.1 (the remote
side will not close the connection after sending the response).

License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) status/in-progress In progress
Projects
None yet
Development

No branches or pull requests

4 participants