user not in /etc/sudoers

[lalkh]

excuse me，I have learned a lot from your exploit methods。And I found it necessary that the user should be in /etc/sudoers when I use exploit_userspec.py,if the user is not in /etc/sudoers,is it possible to exploit?

[worawit]

No. The user is not in /etc/sudoers should be easier.

the checking function iterates from last rule to first rule.
If the user is NOT in sudoers, overwriting only first userspec is enough.
If the user is in sudoers, you have to overwriting first userspec (for cleanup without a crash) and a userspec before the user one (because iterating do "curr->prev->prev->next" instead of "curr->prev").

Note:

• current exploit_userspec.py does not work when only 1 rule is in /etc/sudoers (including rules in /etc/sudoers.d/*). might fix if this case exists
• if the user is in /etc/sudoers (and no explicit PASSWD in the rule), you can overwrite only defaults (see exploit_defaults_mailer.py as an example) by setting def_authenticate to 0

[lalkh]

Note:
current exploit_userspec.py does not work when only 1 rule is in /etc/sudoers (including rules in /etc/sudoers.d/*). might fix if this case exists
yes, this situation is what I faced，because I‘m not clear what kind of data I have to overwrite. I have to say bruteforce stack_addr is really a genius idea，I found 0x7ffxxxx00000 is always 0x7ffexxx00000 on my system,I have modified that and It works on my system. By the way, It would be awesome that you would implement that scenario.

[worawit]

I added support 1 rule in /etc/sudoers for exploit_userspec.py.

Can you try it and give me a result?

[lalkh]

Yes, It is now work on my system. And I found it doesn't work on my ubuntu16.04.6

offset to first userspec: 0x370
offset_max: 0x280
offset_min: 0x180
at range: 0x0-0x70

cmnd size: 0x1230
offset to defaults: 0x60
offset to first userspec: 0x370
offset to userspec: 0x1d0

to skip finding offsets next time no this machine, run:
exploit_userspec.py 0x1230 0x60 0x370 0x1d0
invalid offset. exit code: 139

[worawit]

I totally forgot this case. Ubuntu 16.04 apport is enabled by default. So exit status is coredump (128) + sigsegv (11).

Fixed it.

Note: apport does coredump on all sigsegv, so the exploit will run much slower.

[lalkh]

When I was in docker,I think the chunks have some difference. bruteforce cannot success even I closed ASLR and use a correct stack addr.