[Galaxy Note 4 Developer Discussion (Devs., Only)] FiniteTime:
I did a little reading last night and found:

https://stackoverflow.com/questions/16325486/using-buffer-overflow-to-execute-shell-code

http://www.eecis.udel.edu/~bmiller/cis459/2007s/readings/buff-overflow.html

http://www.cse.scu.edu/~tschwarz/coen152_05/Lectures/BufferOverflow.html

from

https://www.google.com/#q=buffer+overflow+run+code

I think you're on the right track [MENTION=4558078]ZPaul2Fresh8[/MENTION] but besides triggering the fd or int overflow, we need to trigger it with something with privileges that we can then leverage to run 4322. If we trigger the overflow with a really restricted process then we're still bound by those restrictions.

Unless I'm totally wrong and you can break through restrictions somehow if successfully triggering an overflow gives free reign. With like exploiting webservers, people say to not run them as root because if they get exploited/hacked, then they have root through the web server.

If you need an apk to base stuff off of I think the two poc repos from the retme7 github are a good place to start. There was that apk to test vulnerability to CVE-2014-7911 but that might be difficult to modify (required like reversing it, didn't sound ideal).

So there's a user "system" on Android that at least 31 processes, including surfaceflinger, run under (some others may start/stop or could be started by us). Here's a list from my N910A running NK3:

/system/bin/servicemanager

/system/bin/rfs_access

/system/bin/qseecomd

/system/bin/secure_storage_daemon

/system/bin/sh

/system/bin/mcDriverDaemon

/system/bin/edmaudit

/system/bin/ddexe

/system/bin/smdexe

/system/bin/connfwexe

/system/bin/ss_conn_daemon

/system/bin/surfaceflinger

/system/bin/drsd

/system/bin/sensorhubservice

/system/bin/npsmobex

/system/bin/qrngd

/system/bin/bintvoutservice

/system/bin/IPSecService

/system/bin/time_daemon

/system/bin/nqs

/system/bin/vcsFPService

system_server

/system/bin/tlc_server

com.sec.imsservice

com.sec.android.easysidepanel

com.qualcomm.qti.services.secureui:sui_service

com.sec.android.inputmethod

com.sec.android.service.bezel

com.android.settings

com.ws.dm

com.samsung.SMT

I'm thinking somehow 'talking to' one of those to get them to add two numbers together and trigger an integer overflow, like zxz0O0 said. Finding out which use libui.so would be good.

But something I'm still puzzling over is (1) how and (2) at what point you write shellcode to the heap (what I read has been talking about the stack but I guess we're working with the heap here). Also the shellcode might need to be specific to the "system" process that is used.

Our shellcode at least should say write out a file with info on its privileges, or depending on how easy it is, try to run the CVE-2014-4322 existing code (or retme7's poc).

Scenarios that come to mind:

A. write shellcode to memory -> talk to process running as system that uses libui and trigger int/fd overflow -> somehow(?) RET to shellcode in memory

B. talk to process running as system that uses libui and trigger int/fd overflow -> somehow(?) write to shellcode to heap and execute

Integer overflows seem easier conceptually but it might turn out to be easier to trigger the file descripter overflow. Whichever process is easiest to exploit.

Also those were just the processes running on my phone under system, there could be others that get started when you run something.

Offtopic but something that might be useful for users of other devices wondering if they're vulnerable to CVE-2015-1474 (GraphicsBuffer). Says it added detection support on the 18th:

https://play.google.com/store/apps/details?id=com.bluebox.trust&hl=en