Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.protocols.dns.bind > #16019
| Path | csiph.com!news.uzoreto.com!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail |
|---|---|
| From | charlie derr <cderr@simons-rock.edu> |
| Newsgroups | comp.protocols.dns.bind |
| Subject | Re: Debian/Ubuntu: Why was the service renamed from bind9 to named? |
| Date | Thu, 23 Jul 2020 10:44:43 -0400 |
| Lines | 84 |
| Approved | bind-users@lists.isc.org |
| Message-ID | <mailman.761.1595515453.942.bind-users@lists.isc.org> (permalink) |
| References | <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2E7F@NICS-EXCH2.sbg.nic.at> <af8c0315-6128-5df0-0800-a2940ebcdbe7@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2F10@NICS-EXCH2.sbg.nic.at> <2b5f4d05-b1a8-760c-3082-43843ed486fe@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2FA1@NICS-EXCH2.sbg.nic.at> <6091f715-d145-ab3f-d09b-5ec502575873@thelounge.net> <BAE9894B-2918-425F-A956-A83F2DBF0EC0@isc.org> <d72122e9-bb51-7756-0298-4a667a78b346@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D30C8@NICS-EXCH2.sbg.nic.at> <5F11E663.1060805@ipinc.net> <7caf7a134151405d805b295dc0c09a68@mail.rrcic.com> <5F15D831.4030707@ipinc.net> <1D095F7E-63E5-4AC0-B7F9-DA3A703DA29C@isc.org> <5F1911E1.9070908@ipinc.net> <alpine.LSU.2.21.2007230537470.26325@flame.m3047> <73d03461-92ef-b199-32c9-5674761f0e92@nixmagic.com> <75140a3f-ce3b-a5cd-33c5-bd231818fab4@simons-rock.edu> |
| NNTP-Posting-Host | lists.isc.org |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8 |
| Content-Transfer-Encoding | 8bit |
| X-Trace | usenet.stanford.edu 1595515492 25965 149.20.1.60 (23 Jul 2020 14:44:52 GMT) |
| X-Complaints-To | action@cs.stanford.edu |
| To | bind-users@lists.isc.org |
| Return-Path | <cderr@simons-rock.edu> |
| X-Original-To | bind-users@lists.isc.org |
| Delivered-To | bind-users@lists.isc.org |
| Autocrypt | addr=cderr@simons-rock.edu; keydata= mQINBE0KZmYBEADIZiF2ecir+7XRuA37myOb2T6vyL9OT/6D7U5w67ZWq56LHPdrwRBiUkGZ YcWsWw5Bx+VmXr293SMDZDU8zSGGejN9zVtJS14cIr4gL3FPYsppMdNCycxagZZYo49vr9iJ R4jGcJDYUbOOCv1cpy8yH48YkQOUt3zgUHORrMtqxpoUKU2iiG5gStCCNJdesxGDVxxf/u+E 4nekX6IvttXpMqnXODZ/vSPOfPQl88o2W5dSuv+oek1sLHk/FW5JK/f7z0NYttnuLbkXPQ47 lwTypgoMXsbHg8Tke8nBPR7jY/QowPko2ZW7qfZxEE5vZ0MWstTfx2yyNWNgYD7oEJynbbbs WIqR0IZiZB6JTd+RYVohfBj7M0/QNuNIEnzpQeau8hVvoeebGR3CZQpj0YG6vDIE05SHw3yd 3XRYDcqbFLtQP+Ipwye5F+9ewPV6qMoFdUHeZuKN3ACvpkxmuVFYwf/4s+VTOK6mCCNDUDrl nAS5One2k6bRtX5xuQnE0+t4oTSgiiepHol7w43p9dR1h3nsLFO9mBgBaAqZUmTBZXRfEHg5 v2Yzvt2I7mkx7XdyasiO96LtYTLg83VA+uc8rsJ9CJmiDcu+FV87Dd0XBNvEonJ2vm6DLQAY PABpAfivJCpmfXmNeSfsH8TYuOSkEAZdF725AMN6Wfr3jh67oQARAQABtCRDaGFybGllIERl cnIgPGNkZXJyQHNpbW9ucy1yb2NrLmVkdT6JAjgEEwECACIFAk0KZmYCGyMGCwkIBwMCBhUI AgkKCwQWAgMBAh4BAheAAAoJELuLPXMxqTZ/G/kP/jlL5VFDaQ2EAMCnoHwuthXtPPgLe9Op QNQPB1MxZSLDPFedhxoPTKUVVCC08mLpWdBktunuGQQTtkeMTvWOrp5M56K7oj8Te16gvVZu D1iPKdrnkcNKunkSH3hvYaeuz4EFi6gCBExYCLX9TB35xa68K7k/q3tpRJp/KSJv8LYdKcsJ PqXsOH1PxtdKXEEXzLeFCVhbSWDk8uZeFOVS09jONLlNVur3+7wxJEF+9D9AIojYK3h0g+m7 joCalMGCPicjGsshzlbTlaf4hn7jEpdld4tV6Qm02VmaqIWbSAimxqI7M+eMMcCDOMzSNbJp DGVo/RdwOlBJNnOoD30TY6iXU5/pqExIda3ZBEzbhP4GCISLoBPMKLmYS9XG1padb8DthrEz bbya6vNWjMLBlM0+R9HCDOegyMQJSzAIvdJ1NHvvd9JVUUmRrsgLrT/nrelA9eF3x9tuEW1J aIMn1XMTAyDDQ1kQOH8B/P372GPNxDkcdmu6MMYI45e5Skv69dTnEsv0aLob5Of1ssV9DVYZ 2Tk4VHD6OdB89UPAU+WUhesgZ/LcbsmiS43hfEnALU55a2gGVvaJ3BvRcDsr5n5p3TOzG7Xt ZSaizTk8uZ0TghNCZJrF0ZDnQinjsUezmAm3cx+M8Fr+LlQTMGORvffh3RoOFDbzyx1nwEL4 8gL2uQINBE0KZmYBEADOkv1WqKqxolf1DU4MbTNLNuaRVpvwrRsg3fNkfCXY4i8Ut/kS6VAd BQ+dyXWonlanXmqC5nnsxWAhJBs8d7qYG2S13MHC3yPsDY4hnnAzysXqGh/Z8YQFgeiaTjkx 1D2VLiBAMxVy8bX3hkjlElgNfTHYiFi11zru3Y3P/1k6FWLbvxu6j/tspVWgbGfQSWDTQd7K iWIwVrkfA3EII+0n54GmcRfiK1OI5is4b1yNgwzTNfhuL1mYzw0YrUsaGQ8Uirm4PrB2+X31 vbOUklzXCtpiX2ZS8Ut+009xkCjAVDY2wxAnPvlHdxaGSMdvwehmgpfDM/vLAFhhIuAq2ETM EYCIfI2Y8bcsz3BDF7Q3ktrBeHaHo3z2P9WXYaaHHJgEiM29QKyHeB4R/qAYkSv5blzL+xLx iZMJjUd3vZXq+Mg56BlsmMFkNV3ygfVEW5bu6HPzy0wsdb0omZRkH4JTdCROpeA7go5xuAfv pEoEgynJjmPy5UJYQ9notNOXk7jjC34fKkcu1y1wMcEeu6u05uWBU+x3fv3W/RmifaoTsR7B 53HPj2Yuk2wk0s1eAUVR9Il4dAqsnjTN/z0RzYHOF07p5u9ozOo8a8TEGsILofE0jnNSjhrk JY/5/pKy83W8NusS37wtjxuXA40YMOn/DlvRsbRhJzhB3Ua12CwtvwARAQABiQIfBBgBAgAJ BQJNCmZmAhsMAAoJELuLPXMxqTZ/tA4P/2DSS6wF4AL73eh9b7Nyy5CGe5rxW3swpXH5rbld PXQMcz5AFnVYcRmFTleHDR9KbNkqzClN2Le5VtOZVnJyugme1JqwgcHwAKeIs6136aT6HpTx qPFhnAWZvB08Qz4gUJ1Jz8VzHFS68RGPL+z90Gwwjb4rraB3ltHugZDvdnvCTY01dq/mtseB pxzhrzA63ij8B3EQ0+6uQJNeOLneO4ICmB+t5Cq3p+RNMvMSYvRCq/a/1PMsFRQL3oUnJcWh qEX0wi6sRNYtFCGcSYc2wHTiUyRVQfPdt9DfETGcyIVcf/J/Kv6xpIXR0KFOj7rhoLhw5InX PyLbz7rYSW4pJOpfT/tEV4ETREFHipyZPlH0k99kxOfAY1FFMpR8GS/UHdombu9S0G+oiRon KEQTEZvkAx+NR3qvV6NjGT1EP36JEz3immLQbMM+6nC5yv8ZgIlvwJK+66fh5M+Hc/YzR6dJ 36fECNmNQOXrKHIMQXxWMS3rsISpW56pysXGmcX8a8oHxuvFWwed0mDyZc1tMvKgxDPYGuln 2ZTZwB6RXMtX+zAASwH7RWM8d8+OR8pcx4ywQ9DEXpSlcCfN3yeez/LqdDjCC/fg+9AceM6J eYH8PCU0jbZFEu3cF9Vd9ktrvXGrkRrUxmqmEqa+OpLqwNsILBZYNrBgAP++M67Au9tM |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 |
| In-Reply-To | <73d03461-92ef-b199-32c9-5674761f0e92@nixmagic.com> |
| Content-Language | en-US |
| X-Spam-Status | No, score=0.0 required=5.0 tests=SPF_HELO_PASS, T_SPF_PERMERROR autolearn=disabled version=3.4.2 |
| X-Spam-Checker-Version | SpamAssassin 3.4.2 (2018-09-13) on mx.pao1.isc.org |
| X-BeenThere | bind-users@lists.isc.org |
| X-Mailman-Version | 2.1.29 |
| Precedence | list |
| List-Id | BIND Users Mailing List <bind-users.lists.isc.org> |
| List-Unsubscribe | <https://lists.isc.org/mailman/options/bind-users>, <mailto:bind-users-request@lists.isc.org?subject=unsubscribe> |
| List-Archive | <https://lists.isc.org/pipermail/bind-users/> |
| List-Post | <mailto:bind-users@lists.isc.org> |
| List-Help | <mailto:bind-users-request@lists.isc.org?subject=help> |
| List-Subscribe | <https://lists.isc.org/mailman/listinfo/bind-users>, <mailto:bind-users-request@lists.isc.org?subject=subscribe> |
| X-Mailman-Original-Message-ID | <75140a3f-ce3b-a5cd-33c5-bd231818fab4@simons-rock.edu> |
| X-Mailman-Original-References | <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2E7F@NICS-EXCH2.sbg.nic.at> <af8c0315-6128-5df0-0800-a2940ebcdbe7@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2F10@NICS-EXCH2.sbg.nic.at> <2b5f4d05-b1a8-760c-3082-43843ed486fe@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D2FA1@NICS-EXCH2.sbg.nic.at> <6091f715-d145-ab3f-d09b-5ec502575873@thelounge.net> <BAE9894B-2918-425F-A956-A83F2DBF0EC0@isc.org> <d72122e9-bb51-7756-0298-4a667a78b346@thelounge.net> <3E18C1A0C550C44DA156DA5DA8ECCC6AB60D30C8@NICS-EXCH2.sbg.nic.at> <5F11E663.1060805@ipinc.net> <7caf7a134151405d805b295dc0c09a68@mail.rrcic.com> <5F15D831.4030707@ipinc.net> <1D095F7E-63E5-4AC0-B7F9-DA3A703DA29C@isc.org> <5F1911E1.9070908@ipinc.net> <alpine.LSU.2.21.2007230537470.26325@flame.m3047> <73d03461-92ef-b199-32c9-5674761f0e92@nixmagic.com> |
| Xref | csiph.com comp.protocols.dns.bind:16019 |
Show key headers only | View raw
Caveat: i'm far from an expert on compiling, linking, disassembling,
etc... (in fact i know *very* little about these domains), so it's
possible my comment/question below won't even really make sense.
Still, i'm not going to learn more without asking, so...
On 7/23/20 9:49 AM, Michael De Roover wrote:
> The idea is pretty interesting, seems like they provide a repository
> with packages compiled with their own compiler that changes various
> memory-related elements. It is true that memory is usually the culprit
> behind security flaws.
>
> According to their page at
> https://polyverse.com/products/polymorphing-linux-security/ :
>
> "Polymorphing takes source code and runs it through a polymorphic
> compiler, changing register usage, function locations, import tables and
> other targets. This produces individually unique binaries that are
> semantically equivalent to the source. Polymorphing applies the compiler
> to the totality of the Linux stack."
>
> For this to work at all though, they'd have to provide all packages
> simply as source code (why not use the distribution's own source
> repositories?) and compile it on the target. But even then I think it's
> more of a security by obscurity thing. Sure it makes it more difficult
> to exploit a memory flaw by means of automated exploits and other such
> scripts. But nothing stops you from taking the unmodified source code,
> the binary and a disassembler to find out how exactly the resulting
> binary has been changed / polymorphed.
While it would still *technically* be security by obscurity, it would
seem to me that there's some value to this approach because access to
the compiled binary wouldn't necessarily be easy to obtain (especially
if the sysadmin provisioning the system takes extra efforts to *not*
share it with anyone). Or am i missing something?
> I'm not very familiar with
> reverse engineering and disassemblers but I don't think there's much
> more to it than that, at least to thwart this defense. All of it is
> possible if an attacker can read, retrieve and execute a binary on the
> affected server. The flaws are still there, only their memory locations
> have changed. It would probably defend against script kiddies, but I
> doubt it would keep out a determined attacker.
>
> Personally I prefer Google's approach to this for Chromium. They
> documented it at
> https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
> . Implementing programs in memory safe languages where possible is
> something I believe to be a more solid long-term solution. Additionally
> Google's Project Zero team is behind a lot of the security research and
> disclosures. They audit the actual code instead, which I believe to be
> far more suitable.
>
> While the idea is valid to some extent (and could be worth it in highly
> confidential environments), I wouldn't consider it worth compiling
> everything from source for, with a nonstandard compiler no less. If
> servers would just be updated more often and (security) bug fixes
> actually make their way through to the distribution releases reliably,
> we'd already go a long way I think. Of course there are also
> configuration mistakes that could compromise a network component. From
> what I've seen so far, this seems to be more often the case with those
> leaked databases and whatnot.
Thanks much for this fascinating discussion,
~c
>
> On 7/23/20 2:39 PM, Fred Morris wrote:
>> Perhaps slightly OT, but here's a company which has a whole business
>> model based on one nonobvious (?) reason to compile from source:
>> https://polyverse.com/
>>
>> --
>>
>> Fred Morris
--
Charlie Derr Director, Instructional Technology 413-528-7344
https://www.simons-rock.edu Bard College at Simon's Rock
Encryption key: http://hope.simons-rock.edu/~cderr/
Personal writing: https://medium.com/@cderr Pronouns: he or they
Home landline: 860-435-1427
Back to comp.protocols.dns.bind | Previous | Next | Find similar
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named? charlie derr <cderr@simons-rock.edu> - 2020-07-23 10:44 -0400
csiph-web