maybe write these personally in the future vs pasting chatbot output? even if you didn't write the code, it would be nice if you wrote the description and post on your own.
I was too! The reason is that the Go x/crypto/ssh library was bailing out on the lack of reply to the channel open request, which prevented it from reaching the auth bypass check via exec. I should have an update out soon with this fixed and a RCE check for this issue.
The test server: $ erl -eval 'ssh:start(), ssh_dbg:on(), ssh:daemon(34222, [{system_dir, "/home/otp/ssh/keys"},{user_dir, "/home/otp/ssh/users/otptest/.ssh"}]).'
The exploit: auth.ScrapeExec(options, addr+" "+tname, res, ses, `os:cmd("touch /tmp/HAXXXED").`)
The Secure Shell (SSH) protocol has survived as an internet-facing management protocol for almost 30 years. Over the decades it has transformed from a single patented codebase to a multitude of implementations available on nearly every operating system and network-connected device.
This presentation dives deep into the Secure Shell protocol, its popular implementations, what's changed, what hasn't, and how this leads to unexpected vulnerabilities and novel attacks. An open source tool, dubbed "sshamble", will be demonstrated, which reproduces these attacks and opens the door for further research.
The CFAA has not been amended, but there was DoJ policy change on enforcement. So everyone is always breaking the law in the course of normal business, and it's still up to the prosector to determine who to go after:
- https://www.justice.gov/opa/pr/department-justice-announces-...
An underrated focus of Metasploit was making defensive tooling more robust. Spoonm's work on SNG (as well as other payload/encoder randomization efforts) was effective at killing static (and arguably ineffective) payload signatures. You can find a related talk on the IDS/protocol side at: https://speakerdeck.com/hdm/thermoptic-camouflage-total-ids-...
Source: co-speaker of the OP referenced presentation
The sell-off of captable.io/LTSE Equity was announced to customers a couple months ago, predating the Carta drama (but many folks picked LTSE specifically because it wasn't Carta).
Erm, qmail had lots of bugs[1], when compiled for 64-bit processors (lots of integer overflows), but djb pushed back and said 64-bit wasn't supported. If anything, qmail is known as the most annoying MTA to package, since no modifications to the source are permitted, and the application has to be built using a massive patch tree instead. The quirky management daemons required to run qmail were also obnoxious and at odds with everything else on the system.
Salient quote below:
>In May 2005, Georgi Guninski published "64 bit qmail fun", three vulnerabilities in qmail (CVE-2005-1513, CVE-2005-1514, CVE-2005-1515):
[snip]
>Surprisingly, we re-discovered these vulnerabilities during a recent qmail audit; they have never been fixed because, as stated by qmail's author Daniel J. Bernstein (in https://cr.yp.to/qmail/guarantee.html):
>>"This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits."
Anything with massive storage and massive compute that doesn't need low latency is a great fit. I still host ~300TiB and ~250 cores at home because the cloud cost would be astronomical. Edit: This is for personal stuff related to internet-wide scan data and domain tracking. See https://github.com/hdm/inetdata
On the investor front it depends on the debt size. Most seed-stage investors would prefer debt to a competing investment amount. Loaning yourself up to a year of lean run-rate is probably fine, but much more (hiring, paid user acq, etc) is going to look weird. Future investors may ask you to write off the loan entirely if the terms are nuts (compounding or high interest rate), but shouldn't bat an eye otherwise.
Regarding contingency plans, you don't need to have a hard repayment date in the loan terms and can let it accrue interest indefinitely (until bankruptcy, acquisition, or otherwise). Unlike traditional convertible debt a founder loan normally doesn't "blow up" into a huge equity stake if not paid back.
If things don't work out and you have the opportunity to roll the founding team into an another company (acquihire), loans are an easy thing to assign value to, even if the IP or goodwill is more difficult. Negotiate the loan repayment as a signing bonus if you can.
If things work out and you either raise money or bootstrap to profitability, you can pay off the loans as it makes sense, or just forgive them outright if that's easier. Either way you probably don't need to involve your whole board to manage it, unlike equity changes.
I get the desire as a founder to obtain the same terms on capital as future investors, but it can put you in a weird place and can complicate future fundraising. Props to anyone who can make it work, but I had good luck with the founder loan process and felt like it was the cheapest way to finish bootstrapping (we did).
Tracking capital contributions as debt is the best choice (after incorporation). Pay yourself back 6% non-compounding interest and make things easy. Don't buy your own equity just to cover short-term expenses. Reach out (email in profile) if you would like to see a template.
Alternatively, refile your articles and stock purchase agreement and tie that capital to the stock purchase or initial contribution. I would still recommend founder loans instead. If you use a SAFE or other convertible debt on amazing terms, future investors may ask for the same terms.
Edit: I financed my startup (https://rumble.run) that way and paid myself back a month ago. Painless all around.
In a similar vein, BitNami makes money licensing full-stack open source components with an integrated installer. I used it/them for a few years and while I wasn't smitten, it got the job done until something better came along. If you want a one-click installer for your mvc + db app, it might be worth looking at.
I honestly thought this was satire for the first half of the article. When did working on SaaS products exempt people from understanding how to deliver software? Should we just remove the first [S] from SaaS?
I see this attitude a ton in conversations with startups. A founder describes their whiz-bang thing, a question comes up about how this works in larger environments, usually followed by a mumbled reply about virtual appliances. Virtual appliances (and to some extent, docker containers) are not the solution, for so many reason, I might run out of space in the comment field listing them. The short version: OS updates, security updates, networking issues, customer-side diagnostics, size, and support for the customer's specific virtualization platform. Docker is great if your customers all use docker and you have the update process sorted out, but that is probably a small fraction of your total market.
In other words, build actual installable software that runs on some set of supported operating systems. Make a DEB, an RPM, maybe an MSI. Build an installer. Have a nifty splash screen. Add desktop links. Don't lose revenue because you can't be bothered to figure out omnibus, nullsoft, or bitrock.
If you are building software, keep in mind that customer environments are insane and should be treated as hostile. Every bit of your software and packaging needs to be paranoid, defensive, and respond well to failures. When something goes wrong, customers are not your QA team (you have one, right?). Don't make them run a thousand commands for you. Build actual diagnostic features into the product. Some organizations (hint: they have lots of money), don't let your icky code talk to the internet. Offline activation, offline updates, and offline diagnostics are super important to counting these folks as customers.
A shortcut to getting com, net, info, org, us, sk, and biz is to give premiumdrops.com $24.95/mo. You can get these for free from the TLD operators, but it takes a few weeks of snail mail (last I checked). The gTLD access via CZDAP is free, but takes a few days for approvals to process.