Date: Mon, 12 Aug 2019 15:50:57 -0700 From: "Dan O'Donnell" <dano@well.com> To: trustedbsd-audit@freebsd.org Subject: Re: Audit Pipe Drops Message-ID: <24140A96-3C1C-4168-9AEE-B9787C9FC7A6@well.com> In-Reply-To: <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net> References: <5247B21D-FB16-4949-85E5-9D0D8B37908C@intraversal.de> <10BE768D-32B6-4457-9A77-8144B941F566@intraversal.de> <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW I do not have an answer either but am also very interested in the = answer. During BSidesLV last week there was a session about fooling OSX into = giving up privileged access [1]. In the Q&A that followed the first = question was =E2=80=9Cwill BSM capture this?=E2=80=9D The speaker had no = idea what BSM is/was so hadn=E2=80=99t tested and couldn=E2=80=99t = answer, but I thought that is a really good question. And it is a really good question in light of this, the basic supposition = and question: >>> aware of. The audit pipe is allowed to drop audit records in the >>> kernel, which eventually is technically inevitable of course. The >>> issue I am facing is finding a reliable solution to avoid this. [1] https://www.bsideslv.org/schedule-2/ = <https://www.bsideslv.org/schedule-2/>; Day 1 / Breaking Ground / Unpacking pkgs: a look inside macOS installer = packages and common security flaws We are hackers, we won=E2=80=99t do as you expect or play by your rules, = and we certainly don=E2=80=99t trust you. JAR files are really = ZIPs=E2=80=A6unzip them! So are DOCX, XLSX, PPTX, etc. Open them up! = macOS applications (.app =E2=80=9C=E2=80=9Dfiles=E2=80=9D=E2=80=9D) are = really browsable directories?! Sweet, let=E2=80=99s do that. Less well known but similarly prevalent are Flat Package Mac OS X = Installer (.pkg) files. These are actually XAR archives containing many = plaintext files (including scripts) with plenty to examine without = installing. In this presentation I=E2=80=99ll walk through extracting the contents = of these installer packages, understanding their structure, and how they = work while highlighting where security issues can come up. To drive the = point home of what can go wrong, I=E2=80=99ll include examples of = security issues I=E2=80=99ve seen in the wild and show how they can be = exploited to elevate privileges and gain code/command execution. After this talk, .pkg files will no longer be opaque blobs to you. = You=E2=80=99ll walk away knowing tools and techniques to examine, = understand what they=E2=80=99re really doing, and a methodology for = finding bugs in them. As a final bonus, I=E2=80=99ll include a subtle = trick or two that can be used on red teams. > On Aug 11, 2019, at 7:10 AM, ASV <asv@inhio.net> wrote: >=20 > Hi, > I personally don't know the answer to your question; I've never tried > to do that. But I'd like to inform you that since 2016 only 2 emails > got a reply on this list. Just for you to know better what to expect > here. >=20 > Good luck. >=20 >=20 >=20 > On Mon, 2019-06-24 at 10:09 +0200, b wrote: >> Hello again, >>=20 >> Could someone please comment on the following? >>=20 >>=20 >>> The FreeBSD Handbook has the notion that =E2=80=9Eaudit event = classes may >>> be customized by modifying the audit_class and audit_event >>> configuration files=E2=80=9C. I assume this could also mean adding = custom >>> audit classes and associating them with the event types of >>> interest. How can this be done programmatically for local audit >>> trails? Are there any code examples available? >>=20 >>=20 >> I am aware that this list is very low traffic. Unfortunately I have >> been unsuccessful in finding another place to discuss bsm. If there >> are other places, please let me know. >>=20 >>=20 >> Thank you, >> Benjamin >>=20 >>=20 >>=20 >>=20 >>> Am 06.06.2019 um 13:37 schrieb b via Darwin-dev < >>> darwin-dev@lists.apple.com>: >>>=20 >>> Hello everyone, >>>=20 >>> I am crossposting this message to the darwin dev list and the >>> trustedbsd-audit list since relevant knowledge might be shared >>> among members of both lists and I was not really sure how to >>> properly present the issue to both lists separately. Also, my post >>> is quite long as it bundles the outcome of several days of >>> debugging. Please excuse. >>>=20 >>> I am currently reading a cloned bsm audit pipe from a user space >>> client on macOS to retrieve information about process creation and >>> operations on the system (pc|ex). In the future I want to add other >>> audit classes as well. I am currently looking at bsmtrace as a >>> reference implementation of the read loop. >>>=20 >>> There is one major issue, though, that took me a while to become >>> aware of. The audit pipe is allowed to drop audit records in the >>> kernel, which eventually is technically inevitable of course. The >>> issue I am facing is finding a reliable solution to avoid this. >>>=20 >>> Drops can occur only in audit_pipe_append (audit_pipe.c) under two >>> conditions, (1) the queue is full or (2) the kernel was not able to >>> allocate memory without blocking. >>>=20 >>> (1) can generally be managed in user space client code. There is >>> only one scenario I found (up to now) where even the maximum audit >>> pipe length is insufficient and that is system wake up procedure. >>> Even before the system emits kIOMessageSystemWillPowerOn there are >>> lots and lots of audit events that eventually max out the audit >>> pipe. >>>=20 >>> (2) can=E2=80=99t be influenced from a user space client, at least = not that >>> I am aware of. This happens sporadically but reproducibly when the >>> system is under a lot of stress, e.g. when a lot of processes are >>> spawned at a time and start executing some audited code. >>>=20 >>> All this leads to several questions of which I am not sure if they >>> qualify as potential bug reports or enhancement requests. I would >>> be more than happy if someone with a better understanding of things >>> could comment on them or even suggest possible solution approaches. >>>=20 >>> - (1) could clearly be solved by increasing the allowed maximum >>> audit pipe length which currently is 1024. This maximum value is >>> probably several years old by now and I could imagine that in the >>> meantime the xnu kernel has become a lot more =E2=80=9Etalkative=E2=80= =9C. Is there >>> some technical limitation that would prevent an increase? >>>=20 >>> - I am wondering how the global audit trail that is written to disk >>> is able to perform better, i.e. does not drop (seemingly), than the >>> cloned audit pipe purely in memory? Is there some penalty >>> associated with passing memory from the kernel to user space? How >>> does the global audit trail not struggle with the M_NOWAIT policy? >>>=20 >>> - Since the audit pipe tries to acquire memory by calling malloc >>> with the M_NOWAIT flag, which I assume happens for a reason, is >>> there some strategy or configuration available from user space to >>> ease the restraint on kernel memory allocation =E2=80=93 or am I = simply out >>> of luck here? >>>=20 >>> - I am surely not an expert on memory allocation and even less so >>> in kernel space. With that said, I imagine that allocating only one >>> block of memory for both, pointer (ape) and memory blob (ape- >>>> ape_record), instead of two separate memory allocations would half >>> the potential for M_NOWAIT failure. >>>=20 >>> - Potential for both (1) and (2) could at least be reduced by >>> further filtering events in the kernel. I am not interested in each >>> and every audit event type. The FreeBSD Handbook has the notion >>> that =E2=80=9Eaudit event classes may be customized by modifying the >>> audit_class and audit_event configuration files=E2=80=9C. I assume = this >>> could also mean adding custom audit classes and associating them >>> with the event types of interest. How can this be done >>> programmatically for local audit trails? Are there any code >>> examples available? >>>=20 >>> I hope this does not come across (too) snarky but my expectation >>> towards a security mechanism is first and foremost reliability. >>> Information loss is definitely not supportive in that. Therefore I >>> either hope for a viable existing solution for my problem or am >>> very eager for a fix to the issues at hand. >>>=20 >>> Thanks, >>> Benjamin >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Darwin-dev mailing list (Darwin-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>>=20 > = https://lists.apple.com/mailman/options/darwin-dev/b-spam%40intraversal.de= >>>=20 >>> This email sent to b-spam@intraversal.de >>=20 >> _______________________________________________ >> trustedbsd-audit@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/trustedbsd-audit >> To unsubscribe, send any mail to " >> trustedbsd-audit-unsubscribe@freebsd.org" --Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools 2.5.1 (build 1044) - https://gpgtools.org iQIzBAEBCgAdFiEE9dMnT0tAdaBButXPLFgDC1jkEL4FAl1R7VEACgkQLFgDC1jk EL46vQ/9HrLFuIArA62W1BKO4eOjL8v6+BVBibDREGwJ5ctFV7aWd+CWntpsMzlm UnqWc4ZzoiWqlKHy0wrd/jTPn+HLw1J46KdG0etWVZ8umGG3iPJMUgPxixr+jxS9 hiPuZ57s6+n4xVn8OBZcYpEmsUO4gEwSEKB5+7Mqsiht3SxG3lETPUuX56EF/xiI VmmAJsdJgQuL+QnYTvGPV4na0Nx6R3d9GmWDLer0j7ItBnUl2IubfSvesZrig9Cd Jf9tIx116AGItgUg6985wETuL66tXbf1zmEEmQC474kvhH1NoEPjTLelqtzVvD7S I5xsk4ALnb9v0qoIMyMzvaEkKLt2C8e91j6u6CvWNrCwpjzKkjLveVvx+ldCTqkK RGlNAFtk7xC11vC6FaUhHJJ27rrFkGx6sj4KZOwwqKs8nW1NZWAD04bVRI9reNjQ 6F+nUBmZCOJgxsGCQtZShvvIwQ5niC5Gi+V9kUTi4HONNB8Yicb66ZrBxBZVTIDm 9tZxW6sgujvH9ZYpLS44LqWa2396iX72z+OWcP+Scoetq37dmY03BCYAmU2D+l4+ EFGZmThCK7UVpU056bfN8Ln5PdYjcsF1lYTeQypMZONWKiGgDMarvwESuT3+3Esy iDoHMpsLg81Gjf8ibA5qWJaR+JW1RIGae0D/x0oFJDyct7+UMCY= =cVMZ -----END PGP SIGNATURE----- --Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24140A96-3C1C-4168-9AEE-B9787C9FC7A6>