Vulnerability: Accounts with ETH loans can not be liquidated if LEther's underlying is set to `address(0)`
Severity: medium

Description:
Setting `address(0)` as LEther's `underlying` is allowed, and the logic in `AccountManager#settle()` and `RiskEngine#_valueInWei()` handles `address(0)` specially, which implies that `address(0)` can be an asset.\\nHowever, if LEther's underlying is set to `address(0)`, the accounts with ETH loans will become unable to be liquidated.\\nGiven that at `AccountManager.sol#L100` in `settle()` and `RiskEngine.sol#L186` in `_valueInWei()`, they both handled the case that the `asset == address(0)`, and in `Registry.sol#setLToken()`, `underlying == address(0)` is allowed:\\nWe assume that `address(0)` can be set as the `underlying` of `LEther`.\\nIn that case, when the user borrows native tokens, `address(0)` will be added to the user's assets and borrows list.\\n```\\nfunction borrow(address account, address token, uint amt)\\n    external\\n    whenNotPaused\\n    onlyOwner(account)\\n{\\n    if (registry.LTokenFor(token) == address(0))\\n        revert Errors.LTokenUnavailable();\\n    if (!riskEngine.isBorrowAllowed(account, token, amt))\\n        revert Errors.RiskThresholdBreached();\\n    if (IAccount(account).hasAsset(token) == false)\\n        IAccount(account).addAsset(token);\\n    if (ILToken(registry.LTokenFor(token)).lendTo(account, amt))\\n        IAccount(account).addBorrow(token);\\n    emit Borrow(account, msg.sender, token, amt);\\n}\\n```\\n\\nThis will later prevent the user from being liquidated because in `riskEngine.isAccountHealthy()`, it calls `_getBalance()` in the for loop of all the assets, which assumes all the assets complies with `IERC20`. Thus, the transaction will revert at L157 when calling `IERC20(address(0)).balanceOf(account)`.\\n```\\nfunction liquidate(address account) external {\\n    if (riskEngine.isAccountHealthy(account))\\n        revert Errors.AccountNotLiquidatable();\\n    _liquidate(account);\\n    emit AccountLiquidated(account, registry.ownerFor(account));\\n}\\n```\\n\\n```\\nfunction _getBalance(address account) internal view returns (uint) {\\n    address[] memory assets = IAccount(account).getAssets();\\n    uint assetsLen = assets.length;\\n    uint totalBalance;\\n    for(uint i; i < assetsLen; ++i) {\\n        totalBalance += _valueInWei(\\n            assets[i],\\n            IERC20(assets[i]).balanceOf(account)\\n        );\\n    }\\n    return totalBalance + account.balance;\\n}\\n```\\n

Impact:
We noticed that in the deployment documentation, LEther is set to init with WETH as the `underlying`. Therefore, this should not be an issue if the system is being deployed correctly.\\n```\\n1. ETH\\n   1. Deploy LEther implementation\\n   2. Deploy Proxy(LEther)\\n   3. call init(WETH), "LEther", "LEth", IRegistry, reserveFactor)\\n   4. call Registry.setLToken(WETH, Proxy)\\n   5. call accountManager.toggleCollateralStatus(token)\\n   6. call Proxy.initDep()\\n```\\n\\nBut considering that setting `address(0)` as LEther's `underlying` is still plausible and the potential damage to the whole protocol is high (all the accounts with ETH loans can not be liquidated), we believe that this should be a medium severity issue.

Recommended mitigation:
Issue Accounts with ETH loans can not be liquidated if LEther's underlying is set to `address(0)`\\nConsider removing the misleading logic in `AccountManager#settle()` and `RiskEngine#_valueInWei()` that handles `address(0)` as an asset;\\nConsider disallowing adding `address(0)` as `underlying` in `setLToken()`.\\nSentiment Team\\nFixed as recommended. PR here.\\nLead Senior Watson\\nConfirmed fix.